SFINAE — substitution failure is not an error: Visual walkthrough

5.2.17 · D2 · Coding › C++ Programming › SFINAE — substitution failure is not an error

Hum assume karte hain ki tumne SFINAE — substitution failure is not an error padh liya hai idea ke liye. Yahan hum construction karte hain.

Step 1 — "Candidate" aakhir hota kya hai

KYA HAI. Do candidates ko imagine karo jo desk par résumés ki tarah lined up hain.

KYUN. SFINAE sirf header dekhta hai. Isliye sabse pehle, hum ko yeh dikhna chahiye ki header kahan khatam hota hai aur body kahan shuru hoti hai — kyunki woh line hi poori rule ki boundary hai.

PICTURE. Signature har card ka shaded band hai upar; body neeche ka plain box hai. SFINAE ki "aankhein" sirf shaded band scan karti hain.

Figure — SFINAE — substitution failure is not an error

Step 2 — Substitution: type ko header mein plug karna

Sabse chote possible template se shuru karte hain:

template <typename T>
void probe(const T& t);

KYA HAI. Humne argument se T deduce kiya, phir header ko rewrite kiya real type paste karke.

KYUN yeh tool aur runtime if nahi? Kyunki yeh compile time par hota hai, koi bhi program run hone se pehle. Ek if ek path program run hote waqt choose karta hai; substitution choose karta hai ki kaunsa candidate exist bhi karta hai program ke janam se pehle. Yahi ek raasta hai "kya is type mein koi member hai?" poochne ka — jawab code compile hone se pehle pata hona chahiye.

PICTURE. Placeholder T header mein ek hole hai; substitution concrete type ko us hole mein drop karta hai.

Step 3 — `decltype` se header mein ek check force karna

Hum sirf yeh nahi chahte ki .size() body mein kaam kare — hum chahte hain ki uski validity header ka hissa ho, taaki failure candidate ko toss kare (Step 1 ka shaded band) crash karne ki jagah.

KYA HAI. Humne ek test expression, t.size(), return type ke andar chhupaaya.

KYUN decltype aur t.size() ko body mein call karna nahi? Kyunki body shaded band ke bahar hai — wahan failure ek hard error hai (parent ka pehla mistake box). decltype return type mein rehta hai, jo header hai. Yahi poora game hai: check ko SFINAE region mein le jaao.

PICTURE. Test expression shaded header band ke andar baitha hai; SFINAE ki aankhein use dekh sakti hain.

Step 4 — Fork: success vs. failure

Ab usi template mein do alag types daalo aur header dekho.

Worked example Do types, do fates

template <typename T>
auto getSize(const T& t) -> decltype(t.size(), size_t{}) { return t.size(); }

T = std::vector<int> → t.size() valid hai → return type size_t hai → candidate survive karta hai.
T = int → int mein .size() nahi hai → expression header mein invalid hai → substitution failure → candidate silently remove ho jaata hai.

KYA HAI. Ek template ne vector ke liye ek living candidate produce kiya, aur int ke liye koi candidate nahi.

KYUN. Yahi SFINAE ka ek kaam hai: shaded band mein failure error nahi hai, woh ek deletion hai. Type khud decide karti hai ki candidate exist karta hai ya nahi.

PICTURE. Ek road fork karti hai: green branch (valid header) candidate ko rakhti hai; magenta branch (invalid header) use bin mein daal deti hai — koi crash nahi, bas gone.

Step 5 — Fallback add karna taaki jawab hamesha "haan ya nahi" ho

Agar getSize(7) sirf ek candidate delete kar deta hai, to tumhe "no matching function" milta hai — ek hard error. Hum error nahi chahte; hum "nahi, iski size nahi hai" wala jawab chahte hain. Toh hum ek doosra candidate add karte hain jo hamesha kaam karta hai lekin hamesha worst match hota hai.

Definition Variadic

... overload

template <typename T>
size_t getSize(...) { return 0; }   // '...' kuch bhi accept karta hai, rank LOWEST hai

Ek ... parameter koi bhi argument match karta hai, isliye yeh hamesha available rehta hai — lekin overload resolution ise har real parameter se neeche rank karta hai. Yeh tabhi jeetta hai jab kuch aur survive nahi karta.

KYA HAI. Humne guarantee ki ki hamesha kam se kam ek surviving candidate hoga.

KYUN ... aur koi normal overload nahi? Kyunki do equally-good survivors ambiguous honge (parent ki teesri mistake). ... deliberately lowest priority hai, isliye yeh kabhi compete nahi karta — yeh sirf leftovers pakadta hai.

PICTURE. Do ranked lanes: fast lane (A) sirf un types ke liye open hai jinmein .size() hai; baaki sabko slow lane (B) mein funnel kiya jaata hai.

Step 6 — Fork ko `bool` mein convert karna (the detection idiom)

Hum actually size nahi chahte — hum fact chahte hain "size-able: haan/nahi" ek compile-time boolean ke roop mein. Same machinery, ek type trait ke roop mein package ki gayi.

template <typename T>
auto test(int) -> decltype(std::declval<T>().size(), std::true_type{});
template <typename T>
std::false_type test(...);
 
template <typename T>
struct has_size : decltype(test<T>(0)) {};   // 0 int ko ... se prefer karta hai

KYA HAI. Do candidates ke beech choice ek single true/false value mein compress ho gayi.

KYUN 0 pass karte hain? 0 ek int hai, aur int, test(int) se test(...) se better match karta hai. Toh int overload pehle try hota hai; sirf agar uska header delete ho tab hum ... par jaate hain. Poora survival-vs-deletion drama ek bit mein collapse ho jaata hai.

PICTURE. Step 4 ki fork ek funnel se squeeze hoti hai jo ek single lamp output karti hai: green lamp = true, magenta lamp = false.

Step 7 — Edge aur degenerate cases jo tumhe miss nahi karne chahiye

Common mistake Boundary ke traps

Header mein nahi, body mein failure. Agar tumne return t.size(); kisi body mein likha jisme koi decltype guard nahi hai, int body tak pahunch jaata hai aur hard-error deta hai. SFINAE kabhi fire nahi hota. Fix: check header mein hona chahiye (Step 3).
Dono overloads ek saath valid. Agar overload A aur ek normal overload B dono viable hain, toh call ambiguous hai — hard error, silent pick nahi. Fix: ek ko strictly worse banao (...) ya conditions ko clean partition banao.
Reference / const types. std::declval<T>() ek T value fake karta hai even un types ke liye jinmein constructor nahi hai, toh check T = const std::string& ke liye bhi kaam karta hai. Iske bina, "T ka ek object chahiye" khud un-constructible types ke liye fail ho jaata.
private members. Agar .size() exist karta hai lekin private hai, toh header expression access-checked hota hai aur fail hota hai → detector correctly false report karta hai.

KYA HAI. Chaar tarike jisme naive picture toot sakti hai, har ek ka apna fix hai.

KYUN. SFINAE precise hai: yeh sirf shaded band ko protect karta hai aur kuch nahi. Upar ke har trap mein tum accidentally band ke bahar step kar lete ho, ya do survivors collide kar jaate hain.

PICTURE. Ek map jisme teen danger zones marked hain: "body zone" (red — crashes), "overlap zone" (orange — ambiguous), aur safe "header zone" (green).

Ek-picture summary

Poori derivation ek canvas par: left se ek type enter karti hai. Usse do headers mein substitute kiya jaata hai. .size() wala header ya toh survive karta hai (green) ya delete hota hai (magenta) SFINAE band ke andar. Variadic ... header hamesha survive karta hai lekin sabse neeche rank karta hai. Overload resolution best rank waale survivor ko pick karta hai, aur choice ek single bool ke roop mein read hoti hai.

Recall Feynman: poora walkthrough plain words mein

Hum ek computer se ek haan/nahi sawaal poochna chahte the program run hone se pehle: "kya is type mein .size() hai?" Normal if yeh nahi kar sakta — woh run karte waqt decide karta hai. Toh humne compiler ka apna résumé-tossing rule use kiya. Pehle humne ek function likha jiske header mein ek chota test hai — decltype(t.size(), ...) — taaki test us part mein rahe jo compiler inspect karta hai (header, body nahi). Agar type mein .size() hai, header sense banta hai aur résumé desk par rehta hai. Agar nahi hai, header gibberish hai aur résumé quietly bin ho jaata hai — koi crash nahi. Phir humne ek lazy backup résumé (...) add kiya jo hamesha apply hota hai lekin hamesha haarta hai, taaki hamesha ek survivor ho. Aakhir mein humne do résumés ko true aur false return karwaya, taaki jo jeette woh simply jawab ho. Edge cases: test header mein rakho (kabhi body mein nahi), kabhi do achhe résumés ko tie mat karne do, aur declval use karo taaki even wo types jinhe tum construct nahi kar sakte, test ho sakein. Yahi detection idiom hai — SFINAE ek compile-time question machine mein badal gaya.

Connections

SFINAE — substitution failure is not an error — woh rule jisse yeh page derive hota hai
decltype and Trailing Return Types — woh tool jo check ko header mein rakhta hai
std::enable_if and Tag Dispatch — usi fork ka boolean-gate variant
Type Traits (std::is_integral, std::void_t) — jawab ko trait ke roop mein package karna
void_t Detection Idiom — Step 6 ki cleaner modern spelling
Overload Resolution — kyun ... hamesha haarta hai aur 0 int ko prefer karta hai
Concepts (C++20) — in sab ka readable replacement