Why should I avoid std::enable_if in function signatures

Put the hack in the template parameters.

The enable_if on template parameter approach has at least two advantages over the others:

readability: the enable_if use and the return/argument types are not merged together into one messy chunk of typename disambiguators and nested type accesses; even though the clutter of the disambiguator and nested type can be mitigated with alias templates, that would still merge two unrelated things together. The enable_if use is related to the template parameters not to the return types. Having them in the template parameters means they are closer to what matters;

universal applicability: constructors don't have return types, and some operators cannot have extra arguments, so neither of the other two options can be applied everywhere. Putting enable_if in a template parameter works everywhere since you can only use SFINAE on templates anyway.

For me, the readability aspect is the big motivating factor in this choice.

---

std::enable_if relies on the "Substition Failure Is Not An Error" (aka SFINAE) principle during template argument deduction. This is a very fragile language feature and you need to be very careful to get it right.

if your condition inside the enable_if contains a nested template or type definition (hint: look for :: tokens), then the resolution of these nested tempatles or types are usually a non-deduced context. Any substitution failure on such a non-deduced context is an error. the various conditions in multiple enable_if overloads cannot have any overlap because overload resolution would be ambiguous. This is something that you as an author need to check yourself, although you'd get good compiler warnings. enable_if manipulates the set of viable functions during overload resolution which can have surprising interactions depending on the presence of other functions that are brought in from other scopes (e.g. through ADL). This makes it not very robust.

In short, when it works it works, but when it doesn't it can be very hard to debug. A very good alternative is to use tag dispatching, i.e. to delegate to an implementation function (usually in a detail namespace or in a helper class) that receives a dummy argument based on the same compile-time condition that you use in the enable_if.

template<typename T>
T fun(T arg) 
{ 
    return detail::fun(arg, typename some_template_trait<T>::type() ); 
}

namespace detail {
    template<typename T>
    fun(T arg, std::false_type /* dummy */) { }

    template<typename T>
    fun(T arg, std::true_type /* dummy */) {}
}

Tag dispatching does not manipulate the overload set, but helps you select exactly the function you want by providing the proper arguments through a compile-time expression (e.g. in a type trait). In my experience, this is much easier to debug and get right. If you are an aspiring library writer of sophisticated type traits, you might need enable_if somehow, but for most regular use of compile-time conditions it's not recommended.

---

Which solution should be preferred and why should I avoid others?

Option 1: enable_if in the template parameter

It is usable in Constructors.

It is usable in user-defined conversion operator.

It requires C++11 or later.

In my opinion, it is the more readable (pre-C++20).

It is easy to misuse and produce errors with overloads: template::value>> void f() {/*...*/} template::value>> void f() {/*...*/} // Redefinition: both are just template f() Notice the use of typename = std::enable_if_t instead of the correct std::enable_if_t::type = 0

Option 2 : enable_if in the return type

It cannot be used with constructors (which have no return type)

It cannot be used in user-defined conversion operator (as it is not deducible)

It can be used pre-C++11.

Second more readable IMO (pre-C++20).

Option 3: enable_if in a function parameter

It can be use pre-C++11.

It is usable in Constructors.

It cannot be used in user-defined conversion operators (they have no parameters)

It cannot be used in methods with a fixed number of arguments, such as unary/binary operators +, -, * and others.

It is safe for use in inheritance (see below).

Changes function signature (you have basically an extra as last argument void* = nullptr); this causes pointers pointers to the function to behave differently and so on.

Option4 (C++20) requires

There is now requires clauses

It is usable in Constructors

It is usable in user-defined conversion operator.

It requires C++20

IMO, the most readable

It is safe to use with inheritance (see below).

Can use directly template parameter of the class template struct Check4 { T read() requires(std::is_same::value) { return 42; } T read() requires(std::is_same::value) { return 3.14; } };

Are there any differences for member and non-member function templates?

There are subtle differences with inheritance and using:

According to the using-declarator (emphasis mine):

namespace.udecl

The set of declarations introduced by the using-declarator is found by performing qualified name lookup ([basic.lookup.qual], [class.member.lookup]) for the name in the using-declarator, excluding functions that are hidden as described below.

...

When a using-declarator brings declarations from a base class into a derived class, member functions and member function templates in the derived class override and/or hide member functions and member function templates with the same name, parameter-type-list, cv-qualification, and ref-qualifier (if any) in a base class (rather than conflicting). Such hidden or overridden declarations are excluded from the set of declarations introduced by the using-declarator.

So for both template argument and return type, methods are hidden is following scenario:

struct Base
{
    template <std::size_t I, std::enable_if_t<I == 0>* = nullptr>
    void f() {}

    template <std::size_t I>
    std::enable_if_t<I == 0> g() {}
};

struct S : Base
{
    using Base::f; // Useless, f<0> is still hidden
    using Base::g; // Useless, g<0> is still hidden
    
    template <std::size_t I, std::enable_if_t<I == 1>* = nullptr>
    void f() {}

    template <std::size_t I>
    std::enable_if_t<I == 1> g() {}
};

Demo (gcc wrongly finds the base function).

Whereas with argument, similar scenario works:

struct Base
{
    template <std::size_t I>
    void h(std::enable_if_t<I == 0>* = nullptr) {}
};

struct S : Base
{
    using Base::h; // Base::h<0> is visible
    
    template <std::size_t I>
    void h(std::enable_if_t<I == 1>* = nullptr) {}
};

Demo

and with requires too:

struct Base
{
    template <std::size_t I>
    void f() requires(I == 0) { std::cout << "Base f 0\n";}
};

struct S : Base
{
    using Base::f;
    
    template <std::size_t I>
    void f() requires(I == 1) {}
};

Demo

---

"Which solution should be preferred and why should I avoid others?"

When the question was asked, std::enable_if from <type_traits> was the best tool available, and the other answers are reasonable up to C++17.

Nowadays in C++20 we have direct compiler support via requires.

#include <concepts
template<typename T>
struct Check20
{
   template<typename U = T>
   U read() requires std::same_as <U, int>
   { return 42; }
   
   template<typename U = T>
   U read() requires std::same_as <U, double>
   { return 3.14; }   
};

---