SFINAE — The Silent enable_if Placement Mistake

Every serious C++ codebase eventually needs functions that behave differently depending on the type they receive — not just at runtime, but at compile time, with zero overhead. That requirement drives a huge amount of template metaprogramming, and right at the heart of it sits SFINAE: Substitution Failure Is Not An Error. It's the mechanism that lets library authors write std::sort, std::to_string, and range-based algorithms that silently work for the right types and refuse to compile for the wrong ones, all without a single if statement at runtime.

Before SFINAE was understood and exploited deliberately, the only tool you had was template specialisation — which forced you to enumerate every type you cared about. SFINAE flipped the model: instead of opting types in, you write constraints that disqualify types that don't satisfy them. The compiler does the selection at compile time, and non-matching overloads vanish as if they never existed.

By the end of this article you'll understand exactly why substitution failure is silently swallowed, how std::enable_if weaponises that behaviour, how void_t detects the presence of member types and functions, how to avoid the classic mistakes that silently break your constraints, and when to throw SFINAE away entirely in favour of C++20 Concepts.

What SFINAE Actually Means at the Compiler Level

When you call a function template, the compiler performs substitution: it replaces each template parameter with the deduced or explicitly provided type and checks whether the resulting signature is well-formed. If that substitution produces an invalid type or expression — say, calling .begin() on an int — the compiler doesn't emit an error. It marks that candidate as 'substitution failed' and removes it from the overload set. This is SFINAE.

The rule only applies to the immediate context of the template declaration — the return type, parameter types, and template parameter list itself. If the failure happens inside the function body, you get a hard compile error, not silent removal. That boundary is the single most important thing to understand about SFINAE, and it's where most bugs hide.

This behaviour is standardised in C++11 (building on earlier practice) and is the backbone of the entire <type_traits> header. Every std::is_integral, std::is_pointer, and std::has_virtual_destructor ultimately uses SFINAE internally to probe types at compile time.

The overload resolution process works like a tournament: every viable candidate competes, SFINAE quietly eliminates the unqualified ones, and the best remaining match wins. If zero candidates survive, then you get an error — 'no matching function call' — which is the only user-visible consequence of a substitution failure.

#include <iostream>
#include <type_traits>

// Overload A — only enters the overload set when T is an integral type.
// The return type is computed: if T is integral, it resolves to void.
// If T is NOT integral, the expression is ill-formed → substitution failure → silently removed.
template <typename T>
typename std::enable_if<std::is_integral<T>::value, void>::type
describe(T value) {
    std::cout << value << " is an integer type\n";
}

// Overload B — enters the overload set only when T is a floating-point type.
template <typename T>
typename std::enable_if<std::is_floating_point<T>::value, void>::type
describe(T value) {
    std::cout << value << " is a floating-point type\n";
}

// Overload C — a catch-all for everything else (neither integral nor floating-point).
// std::enable_if with a negated condition: only active when both above are inactive.
template <typename T>
typename std::enable_if<
    !std::is_integral<T>::value && !std::is_floating_point<T>::value,
    void
>::type
describe(T /*value*/) {
    std::cout << "Type is neither integral nor floating-point\n";
}

int main() {
    describe(42);          // Selects Overload A — int is integral
    describe(3.14);        // Selects Overload B — double is floating-point
    describe("hello");     // Selects Overload C — const char* is neither

    // describe('A') would select Overload A — char IS integral in C++
    describe('A');         // Integral: char → prints as integer value 65

    return 0;
}

std::enable_if, void_t and Detection Idiom — Your Real Toolbox

std::enable_if<Condition, T> is the standard SFINAE workhorse. When Condition is true, it exposes a nested ::type equal to T (defaulting to void). When Condition is false, there is no ::type — accessing it is ill-formed, which triggers substitution failure and removes that overload. Simple, predictable, and everywhere.

But enable_if works on traits — pre-computed boolean properties. What if you want to check whether a type has a specific member function or nested type that no trait covers? That's where void_t (C++17, but trivially implementable in C++11) shines. void_t<Expr> maps any valid expression to void, and any invalid expression to substitution failure. You use it to write detector partial specialisations.

The detection idiom combines a primary template (returns a default 'not detected' type) with a partial specialisation gated by void_t. If the expression inside void_t is valid, the specialisation wins. If not, the primary template wins. No macros, no runtime cost, fully composable.

C++11 users can implement void_t as a one-liner variadic alias template. It's not magical — it's just an alias that discards its arguments after validating them.

#include <iostream>
#include <string>
#include <type_traits>
#include <vector>

// ── void_t: C++11 compatible implementation ──────────────────────────────────
// Accepts any number of well-formed types, then collapses to void.
// If any type expression is invalid, the entire alias is ill-formed → SFINAE.
template <typename...>
using void_t = void;
// (This is std::void_t in C++17 — shown here so you understand what it really is.)

// ── Detector: does type T have a member function .serialize() ? ──────────────

// Primary template: assume T does NOT have serialize().
// 'HasSerialize::value' will be false_type for types without it.
template <typename T, typename = void>
struct HasSerialize : std::false_type {};

// Partial specialisation: only activates when decltype(&T::serialize) is a
// well-formed expression — i.e., T genuinely has a member called 'serialize'.
// void_t swallows the decltype result, producing void, matching the default
// second parameter 'void'. The specialisation wins over the primary.
template <typename T>
struct HasSerialize<T, void_t<decltype(&T::serialize)>> : std::true_type {};

// ── Detector: does type T have a nested type called 'value_type'? ────────────
template <typename T, typename = void>
struct HasValueType : std::false_type {};

template <typename T>
struct HasValueType<T, void_t<typename T::value_type>> : std::true_type {};

// ── Types to probe ────────────────────────────────────────────────────────────
struct JsonDocument {
    std::string serialize() const { return "{}"; }  // Has serialize()
};

struct RawBuffer {
    char data[256];  // No serialize(), no value_type
};

// ── Functions that use the detectors ─────────────────────────────────────────

// Only compiles into the overload set when T has serialize().
template <typename T>
typename std::enable_if<HasSerialize<T>::value, std::string>::type
convertToString(const T& obj) {
    return obj.serialize();  // Safe to call — we proved it exists at compile time
}

// Fallback: T doesn't have serialize(), so we return a placeholder.
template <typename T>
typename std::enable_if<!HasSerialize<T>::value, std::string>::type
convertToString(const T& /*obj*/) {
    return "[not serializable]";
}

int main() {
    JsonDocument doc;
    RawBuffer    buf;
    std::vector<int> numbers = {1, 2, 3};  // Has value_type, no serialize()

    std::cout << "JsonDocument has serialize(): "
              << std::boolalpha << HasSerialize<JsonDocument>::value << "\n";  // true
    std::cout << "RawBuffer has serialize():    "
              << HasSerialize<RawBuffer>::value    << "\n";  // false

    std::cout << "vector has value_type: "
              << HasValueType<std::vector<int>>::value << "\n";  // true
    std::cout << "RawBuffer has value_type: "
              << HasValueType<RawBuffer>::value        << "\n";  // false

    // SFINAE-based dispatch in action:
    std::cout << "\nconvertToString(doc): " << convertToString(doc) << "\n";
    std::cout << "convertToString(buf): " << convertToString(buf) << "\n";

    return 0;
}

SFINAE on Template Parameters vs Return Types vs Function Parameters

There are three syntactic positions where you can place your SFINAE constraint, and each has different ergonomics. Choosing the wrong one leads to ambiguous overloads or constraints that silently don't fire.

Return type position is the classic approach (enable_if as the return type). It works, but it's noisy — the meaningful return type gets buried. It also can't be used on constructors, which have no return type.

Template parameter list position (a defaulted non-type template parameter) is cleaner and works on constructors. The idiom is typename = std::enable_if_t<Condition>. Since default template arguments don't participate in template argument deduction, two overloads with different conditions but otherwise identical signatures can coexist without ambiguity — as long as the conditions are mutually exclusive.

Function parameter position (an extra parameter defaulting to nullptr) is the least preferred. It changes the function's signature visibly, which can interfere with function pointers and virtual dispatch.

In production code, prefer the template parameter position for most cases. Use return type position when the condition naturally expresses the return type (e.g., enable_if<is_pointer<T>::value, T>). Avoid function parameter position except in legacy code bases.

With C++14 and later, std::enable_if_t<Cond, T> (the _t alias) eliminates the ::type suffix noise. With C++17 and variable templates, std::is_integral_v<T> eliminates the ::value suffix. Always use the shorter aliases — they reduce typo-induced hard errors.

#include <iostream>
#include <type_traits>
#include <string>

// ════════════════════════════════════════════════════════
// POSITION 1: Return type (classic, verbose)
// ════════════════════════════════════════════════════════

template <typename NumericType>
std::enable_if_t<std::is_arithmetic_v<NumericType>, std::string>
formatValue_returnPos(NumericType val) {
    // enable_if_t resolves to std::string only when NumericType is arithmetic.
    // If not arithmetic → std::string doesn't exist here → substitution failure → removed.
    return "[arithmetic] " + std::to_string(val);
}

// ════════════════════════════════════════════════════════
// POSITION 2: Template parameter list (preferred, clean)
// The second template param has a default — it doesn't appear in the call syntax.
// ════════════════════════════════════════════════════════

template <
    typename NumericType,
    // When condition is false, enable_if_t has no 'type' → ill-formed → SFINAE removal.
    // 'nullptr_t' is the type, '= nullptr' provides a default so callers don't pass it.
    std::enable_if_t<std::is_arithmetic_v<NumericType>, int> = 0
>
std::string formatValue_paramPos(NumericType val) {
    return "[arithmetic] " + std::to_string(val);
}

// Non-arithmetic overload that coexists cleanly:
template <
    typename StringLikeType,
    std::enable_if_t<!std::is_arithmetic_v<StringLikeType>, int> = 0
>
std::string formatValue_paramPos(const StringLikeType& val) {
    // This overload wins for std::string, const char*, and anything else non-arithmetic.
    // Conditions are mutually exclusive → no ambiguity, no compiler fights.
    (void)val; // silence unused-param warning in this demo
    return "[non-arithmetic]";
}

// ════════════════════════════════════════════════════════
// POSITION 3: Function parameter (avoid — shown for completeness)
// An extra 'phantom' parameter with a default value carries the constraint.
// Problem: it changes the visible function signature.
// ════════════════════════════════════════════════════════

template <typename NumericType>
std::string formatValue_funcParam(
    NumericType val,
    std::enable_if_t<std::is_arithmetic_v<NumericType>, int> = 0  // phantom param
) {
    return "[arithmetic] " + std::to_string(val);
}

int main() {
    // All three positions produce identical runtime behaviour:
    std::cout << formatValue_returnPos(42)       << "\n";  // Position 1
    std::cout << formatValue_returnPos(3.14f)    << "\n";  // Position 1

    std::cout << formatValue_paramPos(100)       << "\n";  // Position 2 — arithmetic
    std::cout << formatValue_paramPos(std::string("hello")) << "\n";  // Position 2 — non-arith

    std::cout << formatValue_funcParam(99)       << "\n";  // Position 3

    // formatValue_returnPos("oops");  // Would be a hard error — no non-arith overload for pos 1

    return 0;
}

SFINAE vs C++20 Concepts — When to Use Each in Production

C++20 Concepts are the language-level answer to 'SFINAE is too hard to write and impossible to read'. A requires clause expresses the same constraints, but with readable error messages, cleaner syntax, and subsumption rules that handle overload priority without mutual exclusion gymnastics.

But SFINAE isn't dead. You'll encounter it in every pre-C++20 codebase, in every header-only library targeting C++14/17, and in the standard library itself. Understanding SFINAE is a prerequisite for reading STL source code, debugging template errors, and maintaining existing infrastructure.

In new code targeting C++20 or later: use Concepts. They compose better, their error messages name the constraint that failed, and the subsumption relationship (a more-constrained template is preferred over a less-constrained one) replaces the fragile mutual-exclusion patterns SFINAE forces you into.

In code that must stay at C++17: use void_t + detection traits for type probing, enable_if_t with the template parameter position for overload control, and wrap complex conditions in named trait structs so the intent is readable.

The performance story is identical: both SFINAE and Concepts are purely compile-time mechanisms. There is zero runtime overhead — eliminated overloads generate no code whatsoever. The difference is entirely in developer ergonomics and compiler diagnostics.

#include <iostream>
#include <type_traits>
#include <concepts>    // C++20
#include <string>
#include <vector>

// ════════════════════════════════════════════════════════
// APPROACH A: Classic SFINAE (C++17 style)
// Works anywhere. Verbose. Error messages are cryptic when misused.
// ════════════════════════════════════════════════════════

template <typename ContainerType,
          std::enable_if_t<
              // Condition: T must have begin() and end() and a value_type
              std::is_same_v<
                  decltype(*std::declval<ContainerType>().begin()),
                  typename ContainerType::value_type&
              >,
              int
          > = 0>
void printAll_sfinae(const ContainerType& container) {
    std::cout << "[SFINAE] Contents: ";
    for (const auto& element : container) {
        std::cout << element << " ";
    }
    std::cout << "\n";
}

// ════════════════════════════════════════════════════════
// APPROACH B: C++20 Concepts — same constraint, crystal clear
// The compiler error if you call this with int? "int doesn't satisfy 'Iterable'".
// ════════════════════════════════════════════════════════

// Define a named concept: T is Iterable if you can call begin() and end() on it.
concept Iterable = requires(ContainerT container) {
    { container.begin() } -> std::input_or_output_iterator;
    { container.end()   } -> std::input_or_output_iterator;
};

template <Iterable ContainerType>
void printAll_concepts(const ContainerType& container) {
    std::cout << "[Concepts] Contents: ";
    for (const auto& element : container) {
        std::cout << element << " ";
    }
    std::cout << "\n";
}

// Subsumption: a more-specific concept is preferred — no mutual exclusion needed.
// This overload also requires the elements to be printable (streamable).
concept PrintableIterable = Iterable<ContainerT> && requires(ContainerT c) {
    // Each element must be streamable to std::ostream
    { std::cout << *c.begin() };
};

// This overload wins over the plain Iterable version when both apply,
// because PrintableIterable *subsumes* Iterable — more constrained wins.
template <PrintableIterable ContainerType>
void printAll_concepts(const ContainerType& container) {
    std::cout << "[Concepts/Printable] Printing " << container.size() << " items: ";
    for (const auto& element : container) {
        std::cout << element << " ";
    }
    std::cout << "\n";
}

int main() {
    std::vector<int>         numbers = {10, 20, 30};
    std::vector<std::string> words   = {"alpha", "beta", "gamma"};

    // SFINAE versions:
    printAll_sfinae(numbers);  // Works
    printAll_sfinae(words);    // Works

    // Concepts versions (subsumed — PrintableIterable overload wins for both):
    printAll_concepts(numbers); // PrintableIterable overload selected
    printAll_concepts(words);   // PrintableIterable overload selected

    // printAll_sfinae(42);     // Hard error: substitution failure with no fallback
    // printAll_concepts(42);   // Clear error: "int does not satisfy Iterable"

    return 0;
}

Expression SFINAE and Detecting Arbitrary Expressions at Compile Time

Beyond member functions and nested types, you often need to check whether an arbitrary expression involving a type is valid — for example, can you call f(std::declval<T>())? Or does T support operator+ with another type? Expression SFINAE uses decltype with unevaluated contexts to probe any expression, combined with void_t or directly in a partial specialisation.

C++11 introduced decltype and declval, making expression SFINAE practical. The trick: write the expression you want to test inside decltype, wrap it in void_t, and use it as a template argument. If the expression is invalid, substitution fails; if valid, the specialisation wins.

This technique is how std::is_constructible, std::is_assignable, and std::is_swappable are implemented. The standard library uses it to check for arbitrary requirements without ever calling the expressions at runtime.

One common pattern is to detect whether a type has a reserve member (like std::vector) — useful in generic code that wants to optimise memory allocations. The detector checks decltype(std::declval<T&>().reserve(0)) — if valid, the type has a reserve that takes a size_t-like argument.

#include <iostream>
#include <type_traits>
#include <vector>
#include <list>
#include <string>

// ── Helper: void_t ───────────────────────────────────────────────────
template <typename...>
using void_t = void;

// ── Detector: does T support reserve(size_t)? ─────────────────────────
template <typename T, typename = void>
struct HasReserve : std::false_type {};

template <typename T>
struct HasReserve<T, void_t<decltype(std::declval<T&>().reserve(0))>> : std::true_type {};

// ── Generic function that reserves capacity if possible, else does nothing ──
template <typename Container>
std::enable_if_t<HasReserve<Container>::value>
maybe_reserve(Container& c, std::size_t n) {
    c.reserve(n);
    std::cout << "Reserved " << n << " elements\n";
}

template <typename Container>
std::enable_if_t<!HasReserve<Container>::value>
maybe_reserve(Container& c, std::size_t n) {
    (void)c; (void)n;
    std::cout << "No reserve, ignored\n";
}

int main() {
    std::vector<int> v;
    std::list<int>   l;
    std::string      s;

    std::cout << "vector has reserve: " << HasReserve<decltype(v)>::value << "\n"; // true
    std::cout << "list has reserve:   " << HasReserve<decltype(l)>::value << "\n"; // false
    std::cout << "string has reserve: " << HasReserve<decltype(s)>::value << "\n"; // true (since C++11)

    maybe_reserve(v, 100);  // "Reserved 100 elements"
    maybe_reserve(l, 100);  // "No reserve, ignored"
    maybe_reserve(s, 100);  // "Reserved 100 elements"

    return 0;
}

Why enable_if Syntax Kills Compilation Errors (and Your Readability)

Stop thinking of enable_if as a feature. It's a bouncer. It decides at compile time which overload gets into the party based on a type trait condition. The syntax is ugly because it has to be: the compiler needs a hard true/false gate before it even tries substitution. The why: you're forcing the compiler to discard invalid candidates silently. The how: put the enable_if on the return type, a default template argument, or a function parameter. Default template argument is the least painful: template<typename T, typename = std::enable_if_t<std::is_integral_v<T>>>. That trailing typename = is the bouncer's clipboard. When the condition is false, there is no valid type for that default argument, so SFINAE kicks in and the template vanishes from overload resolution. No error, just silence. But here's the trap: the resulting error messages when you mess up the condition are cryptic. You get 'no matching function' instead of 'you passed a string to an int-only function'. That silent failure is why production code reviews flag raw enable_if everywhere. It buys compile-time safety at the cost of debugging nightmares.

// io.thecodeforge
#include <type_traits>
#include <iostream>

// Bad: SFINAE on return type - least readable
template<typename T>
std::enable_if_t<std::is_integral_v<T>, void> process(T val) {
    std::cout << "Integral: " << val << '\n';
}

// Better: SFINAE on default template argument
template<typename T, typename = std::enable_if_t<std::is_floating_point_v<T>>>
void process(T val) {
    std::cout << "Floating: " << val << '\n';
}

int main() {
    process(42);      // Integral overload
    process(3.14);    // Floating overload
    // process("hello"); // Would fail: no matching function
}

The Hidden Costs of SFINAE That No One Tells Juniors

Let's cut through the theory and talk about what actually happens when you deploy SFINAE in production. I've seen teams burn weeks on these five traps.

1. Compile-Time Cost: Exponential Template Instantiation

SFINAE isn't free. Every enable_if condition forces the compiler to instantiate and discard failed candidates. With deep chains, this explodes combinatorially.

Real numbers: A project I inherited used nested enable_if for a type-safe dispatch layer. Full rebuild: 8 minutes. After porting to C++20 concepts: 2 minutes. The difference? Concepts short-circuit evaluation; SFINAE evaluates all candidates before discarding.

```cpp // SFINAE version — each call instantiates N templates template<typename T, typename = std::enable_if_t<std::is_integral_v<T>>> void process(T) { / int / }

template<typename T, typename = std::enable_if_t<std::is_floating_point_v<T>>> void process(T) { / float / }

// 10 overloads = 10 instantiations per call

// Concepts version — single check, no discarded instantiation template<std::integral T> void process(T) { / int / }

template<std::floating_point T> void process(T) { / float / } ```

2. Error Message Quality: The Wall of Text

When SFINAE fails to match, compilers vomit pages of substitution failures. Here's a real error from GCC 12 with a missing value_type:

`` error: no matching function for call to 'process(MyType)' candidate: template<class T, class> void process(T) candidate: template<class T, class> void process(T) ... 47 lines of substitution failures ... note: candidate expects 0 arguments, 1 provided ``

Concepts version: `` error: no matching function for call to 'process(MyType)' note: constraints not satisfied note: 'MyType' does not satisfy 'std::integral' ``

One is a puzzle hunt. The other tells you exactly what's wrong.

3. Debugging Workflow: Reading the Tea Leaves

When you're debugging SFINAE failures at 3am:

• -ftemplate-backtrace-limit=0 (GCC/Clang) — removes the truncation that hides the real error
• Look for the first substitution failure, not the last. The compiler tries candidates in order; the first failure is usually the root cause.
• Place static_assert as an escape hatch:

``cpp template<typename T> void process(T) { static_assert(sizeof(T) == 0, "process() requires integral or floating point type"); } ``

This catches all failed matches with a single, readable message.

4. Code Maintenance: enable_if Chains Are Unreadable in 6 Months

I've seen codebases where enable_if chains span 20 lines. Six months later, nobody knows what they do. The fix: name your constraints as type aliases.

```cpp // Bad — what does this even mean? template<typename T, typename = std::enable_if_t< std::is_integral_v<T> && !std::is_same_v<T, bool> && (sizeof(T) <= 8)>> void fast_copy(T);

// Good — self-documenting template<typename T> using is_fast_integral = std::bool_constant< std::is_integral_v<T> && !std::is_same_v<T, bool> && (sizeof(T) <= 8)>;

template<typename T, typename = std::enable_if_t<is_fast_integral<T>::value>> void fast_copy(T); ```

5. ODR Violations from SFINAE in Headers

This one bites hard. If the same template with different enable_if conditions appears in different translation units, you get undefined behavior — no diagnostic required.

```cpp // TU1.cpp template<typename T, typename = std::enable_if_t<std::is_integral_v<T>>> void foo(T) { / A / }

// TU2.cpp template<typename T, typename = std::enable_if_t<!std::is_integral_v<T>>> void foo(T) { / B / }

// ODR violation — two definitions of foo with same template-head ```

The fix: never let enable_if conditions vary between TUs. Use explicit specializations or concepts (which are part of the signature).

// io.thecodeforge
#include <type_traits>
#include <vector>

// Bad: raw SFINAE chain in signature - every instantiation is slow
template<typename T,
    typename = std::enable_if_t<
        std::is_same_v<T, std::vector<int>> ||
        std::is_same_v<T, std::vector<double>>>>
void process_vec(T& vec);

// Good: isolate logic into a type trait helper
template<typename T>
struct is_int_or_double_vec : std::false_type {};

template<>
struct is_int_or_double_vec<std::vector<int>> : std::true_type {};

template<>
struct is_int_or_double_vec<std::vector<double>> : std::true_type {};

template<typename T,
    typename = std::enable_if_t<is_int_or_double_vec<T>::value>>
void process_vec_safe(T& vec);

if constexpr vs SFINAE — Which One Belongs in Your Codebase

## 1. What if constexpr (C++17) buys you vs SFINAE

if constexpr lets you write a single function body with compile-time branches. No overload explosion, no enable_if noise, no template gymnastics. The compiler discards the false branch at compile time — but only if the condition is a constant expression.

```cpp // SFINAE: three overloads, each with enable_if

template<typename T, std::enable_if_t<std::is_integral_v<T>, int> = 0> void handle(T t) { / integral path / }

template<typename T, std::enable_if_t<std::is_floating_point_v<T>, int> = 0> void handle(T t) { / float path / }

template<typename T, std::enable_if_t<!std::is_integral_v<T> && !std::is_floating_point_v<T>, int> = 0> void handle(T t) { / class/other path / }

// if constexpr: one function, clear branches

template<typename T> void handle(T t) { if constexpr (std::is_integral_v<T>) { // integral path } else if constexpr (std::is_floating_point_v<T>) { // float path } else { // class/other path } } ```

## 2. When SFINAE wins

SFINAE wins when you need different signatures per type — different return types, different parameter lists, or class template specialisation. if constexpr cannot change the function signature; it only controls which statements execute.

```cpp // SFINAE: different return types

template<typename T, std::enable_if_t<std::is_integral_v<T>, int> = 0> int convert(T t) { return static_cast<int>(t); }

template<typename T, std::enable_if_t<std::is_floating_point_v<T>, int> = 0> double convert(T t) { return static_cast<double>(t); }

// if constexpr cannot do this — return type must be consistent ```

Class template specialisation is another SFINAE-only domain:

```cpp template<typename T, typename = void> struct Foo; // primary template, possibly undefined

template<typename T> struct Foo<T, std::enable_if_t<std::is_integral_v<T>>> { // integral specialisation };

template<typename T> struct Foo<T, std::enable_if_t<std::is_floating_point_v<T>>> { // float specialisation }; ```

## 3. Side-by-side: compile output difference

```cpp // SFINAE version — each overload is a separate function // Compiler output (simplified): // void handle<int>(int) // void handle<double>(double) // void handle<std::string>(std::string)

// if constexpr version — one function, branches discarded // Compiler output: // void handle<int>(int) // void handle<double>(double) // void handle<std::string>(std::string) // Same object code, but source is simpler. ```

## 4. The key limitation: template instantiation in non-constexpr contexts

if constexpr does not prevent template instantiation of the discarded branch in non-constexpr contexts. The branch is not executed, but the compiler still parses and instantiates the template for that branch if the template is instantiated. This can cause compilation errors if the discarded branch uses operations not valid for the type.

``cpp template<typename T> void process(T t) { if constexpr (std::is_integral_v<T>) { t += 1; // OK for int } else { t.size(); // ERROR if T is int, even though branch is discarded // The compiler still instantiates this branch for T=int // and fails because int has no .size() } } ``

Fix: Use if constexpr with type-dependent expressions that are valid for all types in the branch, or use SFINAE to exclude the branch entirely.

## 5. Decision rule

• Single function, one template param, just branching on a trait → if constexpr. Clean, readable, no overload explosion.
• Multiple overloads with different signatures → SFINAE (or Concepts in C++20).
• New code targeting C++20 → Concepts. They replace both SFINAE and if constexpr for most cases, with cleaner syntax and better error messages.

```cpp // C++20 Concepts: the best of both worlds

template<std::integral T> void handle(T t) { / integral / }

template<std::floating_point T> void handle(T t) { / float / }

template<typename T> requires (!std::integral<T> && !std::floating_point<T>) void handle(T t) { / other / } ```