Home > Article > Backend Development > Should You Avoid `std::enable_if` in Function Signatures?
Scott Meyers' upcoming book, EC 11, advises avoiding std::enable_if in function signatures. Despite its versatility in conditionally removing functions or classes from overload resolution, certain limitations and readability issues warrant reconsideration of its usage.
Function Parameter:
<code class="cpp">template<typename T> struct Check1 { template<typename U = T> U read(typename std::enable_if< // Option 1: As function parameter std::is_same<U, int>::value >::type* = 0) { return 42; } };</code>
Template Parameter:
<code class="cpp">template<typename T> struct Check2 { template<typename U = T, typename std::enable_if< // Option 2: As template parameter std::is_same<U, int>::value, int >::type = 0> U read() { return 42; } };</code>
Return Type:
<code class="cpp">template<typename T> struct Check3 { template<typename U = T> typename std::enable_if<std::is_same<U, int>::value, U>::type read() { // Option 3: As return type return 42; } };</code>
The optimal solution involves placing the enable_if in the template parameters. This approach offers several advantages:
Readability Enhancement:
The enable_if usage is separated from return/argument types, improving clarity and reducing clutter.
Universal Applicability:
Unlike the other options, the template parameter placement is applicable to constructors and operators without additional arguments.
Return Type Exclusion:
While "Avoid std::enable_if in function signatures" primarily addresses its use in normal function signatures, it does apply to return types in template specializations. The concern stems from readability issues when merging enable_if with return types.
Member vs. Non-Member Functions:
The principle holds true for both member and non-member function templates.
The above is the detailed content of Should You Avoid `std::enable_if` in Function Signatures?. For more information, please follow other related articles on the PHP Chinese website!