mjhjmtu

I am trying to learn what SFINAE is. I believe I understand it quite well; however, I do not have a lot of practice in the subject. I mean I would find it difficult to list all the cases in which SFINAE should or could be used, or it would be difficult for me to immediately understand what a given sample of an SFINAE code should do. However, I believe I understand the core concept well enough to use it effectively.

Nonetheless looking through examples of SFINAE usage I came to the few conclusions.

One of which is: it is extremely pointless to use a chain of std::enable_if_t, std::void_t, std::is_same, etc, etc, etc, to define a single type using type = int *. IMHO (of a "newbie" with untrained eyes) such chains make the code less (extremely less) readable.

The second conclusion was: wouldn't it be useful to have the ability to check few conditions at the same time?

So I created this alias: (well "created" is waaay too big word... I just wrote 4 lines of code...)

template<typename T, typename ...>
using sfinae = T;

template<typename T, typename ...>
using SFINAE = T;

Usage examples

// 1) within class declaration:
template <typename T, 
 sfinae<bool,
 std::enable_if_t<std::is_integral_v<T>>,
 std::enable_if_t<std::is_arithmetic_v<T>>
 > = true /* provide default option, bc reasons */>
class foo;

// 2) within function declaration:
template <typename T, 
 sfinae<bool,
 std::enable_if_t<std::is_integral_v<T>>,
 std::enable_if_t<std::is_arithmetic_v<T>>
 > = true /* provide default option, bc reasons */>
void foo;

// 3) as a function return type:
template <typename T> 
sfinae<T,
 std::enable_if_t<std::is_integral_v<T>>,
 std::enable_if_t<std::is_arithmetic_v<T>>
> const & foo(T const & val);

// 4) To define other SFINAE-conditions as aliases:
template <typename T> 
using check_xyz = sfinae<void,
 std::enable_if_t<std::is_integral_v<T>>,
 std::enable_if_t<std::is_arithmetic_v<T>>
>;

template <typename T, typename = check_xyz<T>>
class foo;

And my main concern/question is: would a professional c++ developer deem sfinae</*...*/> (as I proposed it) useful or extremely unnecessary? Are there any changes that could be introduced to the idea?

I just wrote four lines of code...

template<typename T, typename ...>
using sfinae = T;

template<typename T, typename ...>
using SFINAE = T;

You should have written just two lines of code — either the first two or the last two. Not both. "There's more than one way to [spell] it" is the Perl way, not the C++ way. ;) (At least not intentionally! Not intentionally pre-C++2a! Now we're getting both std::filesystem and std::fs, that's a less airtight position.)

As you show, your thing can be used for

template<class T, 
 sfinae<bool,
 std::enable_if_t<std::is_integral_v<T>>,
 std::enable_if_t<std::is_arithmetic_v<T>>
 > = true>
void foo();

However, this is pretty verbose; surely we'd rather write std::enable_if_t<std::is_integral_v<T> && std::is_arithmetic_v<T>> than std::enable_if_t<std::is_integral_v<T>>, std::enable_if_t<std::is_arithmetic_v<T>>.

So personally I have a different alias that accomplishes the same goal: bool_if_t.

template<bool B>
using bool_if_t = std::enable_if_t<B, bool>;

template<class T, 
 bool_if_t<
 std::is_integral_v<T> &&
 std::is_arithmetic_v<T>
 > = true>
void foo();

This has the advantage that the inner expression is written using normal C++ syntax rules. We don't have to remember some arbitrary rule like "x, y means both x and y must be true"; we just write x && y. And if we want to enable this function when either x or y is true, we don't have to invent a new primitive; we just write bool_if_t<x || y>. bool_if_t is much more composable than your sfinae<Ts...>, because bool_if_t can exploit the existing expression syntax of C++.

Recommended viewing: "A Soupçon of SFINAE" (Arthur O'Dwyer, CppCon 2017). (Yes, that's me.)

You picked examples that don't really show off the power of sfinae, by the way.
Consider this example:

// 3) as a function return type:
template <typename T> 
sfinae<T,
 std::enable_if_t<std::is_integral_v<T>>,
 std::enable_if_t<std::is_arithmetic_v<T>>
> const & foo(T const & val);

You take a "value-space" boolean (is_integral_v<T>), lift it up into "SFINAE-space" with enable_if_t, and then apply a logical AND operation in SFINAE-space using your sfinae alias.

template <typename T> 
std::enable_if_t<
 std::is_integral_v<T> &&
 std::is_arithmetic_v<T>, T
> const & foo2(T const & val);

Here I take the same "value-space" boolean, perform the logical AND in value space where we have a dedicated operator && for maximum expressiveness; and I lift it up into SFINAE-space after doing the AND. This is clearer and also probably more efficient in terms of compile time.

Where your version helps is when your values start in SFINAE-space!

template<class T> 
sfinae<T,
 decltype(std::declval<T>() + std::declval<T>()),
 T*,
 T&
> const & foo3(T const & val);

If we were trying to replicate this code's behavior with the standard tools, we'd say something like

template<class, class=void> struct has_plus : std::false_type ;
template<class T> struct has_plus<T, decltype(void(std::declval<T>() + std::declval<T>()))> : std::true_type ;
template<class T> inline constexpr bool has_plus_v = has_plus<T>::value;

template<class T> 
std::enable_if_t<
 has_plus_v<T> &&
 not std::is_reference_v<T> &&
 not std::is_void_v<T>, T
> const & foo4(T const & val);

That is, we start with a value in SFINAE-space (decltype(std::declval<T>() + std::declval<T>())), lift it into value-space (has_plus_v<T>), do the logical AND in value-space, and lift the result back into SFINAE-space.

Whereas with your foo3, you start in SFINAE-space, do the logical AND via sfinae<...> without leaving SFINAE-space, and then you're done. Much simpler! But harder to read, I think.

A simple way to improve readability is to pick a good name. sfinae_space_and<Ts...> might be clearer. Can you think of a way to write sfinae_space_or<Ts...>? How about sfinae_space_not<T>? Does it make sense, maintainability-wise, to provide one without the others?

A bit dated...

First of all, let me say that since C++20 much of SFINAE will be unnecessary. Concepts have SFINAE enabled by default, have much nicer syntax, and have greater reuse capabilities.

Code Review

Personally I don't see much improvement over original one. What I would prefer instead of

template <typename T, typename ... >
...

is

template <typename T, bool ... Conditionals>
... //perform folding

Even then, people sometimes have non-trivial logic like AND-ing and OR-ing the results of conditionals.

Much of the complexity lies in that conditional statements, which could be moved away by using something like template variable:

template <typename T>
constexpr inline bool supports_xxx = /*is_same, trivial, etc*/;

and then people could just use

template <typename T, typename = std::enable_if_t<supports_xxx<T>>>
...

Example

// 1) within class declaration:
template <typename T, 
 sfinae<bool,
 std::enable_if_t<std::is_integral_v<T>>,
 std::enable_if_t<std::is_arithmetic_v<T>>
 > = true /* provide default option, bc reasons */>
class foo;

is better written as

template <typename T>
constexpr inline bool is_int_arithmetic_v = std::is_integral_v<T> 
 && std::is_arithmetic_v<T>;

template <typename T, 
 typename = std::enable_if_t<is_int_arithmetic_v<T>>>
class foo;

Do note the inline, it will help users of the code to deal with ODR issues.

template <typename T, 
 sfinae<bool,
 std::enable_if_t<std::is_integral_v<T>>,
 std::enable_if_t<std::is_arithmetic_v<T>>
 > = true /* provide default option, bc reasons */>
class foo;

vs

template <typename T, 
 std::enable_if_t<
 std::is_integral_v<T>
 && std::is_arithmetic_v<T>,
 bool
 > = true
class foo;

This version doesn't use your new sfinae template, and uses fewer characters, and seems no less functional.

What more in C++20 we'll have named concepts (and failing that) requires clauses. That will make much SFINAE obsolete.

What more, there are fancier ways to do SFINAE, especially in c++20

There is this:

template<template<class...>class, class...>
struct can_apply;

which tests if a template can be applied to a list of types.

With constexpr lambdas that can appear in template non type parameter argument calculations, we can do:

template<class F>
constexpr auto apply_test(F &&);

which returns an object that, when evaluated on some arguments, returns true_type if you can invoke F on it, and false_type otherwise.

template<class T,
 std::enable_if_t<
 apply_test((auto a, auto b)RETURNS(a+b))( std::declval<T>(), std::declval<T>() ),
 bool
 > = true
>
struct foo;

here we test if a type T can be added to itself. (I also use the somewhat ubiquitous RETURNS macro)

Or, more cleanly:

template<class T>
auto foo( T const& lhs, T const& rhs )
requires test_apply(std::plus<T>)(lhs, rhs)

assuming sufficiently SFINAE friendly std::plus<T>.