Macro for (SFINAEd) template function - c++

Question

#define BINDINGTEMPLATE template<typename T, typename = typename std::enable_if_t < std::is_same_v<typename std::decay_t<T>, int> || std::is_same_v<typename std::decay_t<T>, std::string> || std::is_same_v<typename std::decay_t<T>, char>>>
Is something like this bad practice?
I am using this function template many times within the same class.
BINDINGTEMPLATE
void myFunction(int x, int y)
{
// do something specialised based on input template
}
For instance, I need to use it in many functions, like this one :

Answer 1

Yes, it's a bad practice. Don't use macros for something that can easily be done without them.
You can move that long SFINAE condition into something like
template <typename T> using foo = std::enable_if_t<...>;
And then you can write simply:
template <typename T, typename = foo<T>>
void myFunction(int x, int y)
Alternatively, you could put the condition into a constexpr function or variable template, then write enable_if_t every time you use it.
Also you could use a concept (requires C++20):
template <typename T>
concept foo = std::is_same_v<typename std::decay_t<T>, int> || etc;
template <foo T>
void myFunction(int x, int y)
Note that this use of enable_if_t (regardless of whether you're using a helper using or not) is not very robust, as the user can circumvent it by explicitly specifying the second template parameter.
A better approach is:
template <typename T, std::enable_if_t<..., std::nullptr_t> = nullptr>
void myFunction(int x, int y)
In addition to being foolproof, this also lets you overload the function based on different traits.
The concepts also solve both problems.

Answer 2

You can achieve the same with a type-trait:
template <typename T>
using enable_if_int_or_string_or_char = std::enable_if_t <
std::is_same_v<typename std::decay_t<T>, int>
|| std::is_same_v<typename std::decay_t<T>, std::string>
|| std::is_same_v<typename std::decay_t<T>, char>>;
Instead of the macro you can then use enable_if_int_or_string_or_char<T>. Macros have severe downsides, so the best macro is the one that you do not need to use.

Answer 3

IMHO, macros are distilled evil.
So, yes: (IMHO) is bad practice.
I propose another way (just for fun: the other answers show good solutions) to avoid it.
You can declare a foo() (SFINAE enabled/disabled function) as follows
template <typename T>
std::enable_if_t<std::is_same_v<std::decay_t<T>, int>
|| std::is_same_v<std::decay_t<T>, std::string>
|| std::is_same_v<std::decay_t<T>, char>> foo ();
you can write your final function using it
template <typename T>
decltype(foo<T>()) bar (int, int)
{ }
The following is a full compiling example
#include <string>
#include <type_traits>
template <typename T>
std::enable_if_t<std::is_same_v<std::decay_t<T>, int>
|| std::is_same_v<std::decay_t<T>, std::string>
|| std::is_same_v<std::decay_t<T>, char>> foo ();
template <typename T>
decltype(foo<T>()) bar (int, int)
{ }
int main ()
{
bar<int>(0, 0); // compile
// bar<long>(0, 0); // compilation error
}

Answer 4

This is an example of trait checking if the type is one of the types you look for:
template <typename T>
struct is_int_string_char
{
static const bool value = std::is_same<std::decay<T>::type, int>
|| std::is_same<std::decay<T>::type, std::string>
|| std::is_same<std::decay<T>::type, char>;
};
You can use it as a constant at compilation type with is_int_string_char<MyType>::value. In your case (if I well understand your code), you can simplify it with:
template <typename T, typename U = std::enable_if<is_int_string_char<T>>

Answer 5

Since C++ provides many other options to solve this, one should not go for macros(IMO).
For instance, you could make a variable template, where you can specify that any of the passed template Types is same as myFunction's template type T, and SFNIAE the solution.
Thanks to c++17's std::disjunction, by which this idea can be generalized for any arbitary number of Types, with less noisy!
#include <string>
#include <type_traits> // std::enable_if_t, std::is_same, std::disjunction_v
template<typename T, typename... Types>
constexpr bool isAcceptableType = std::disjunction_v<std::is_same<T, Types>...>;
template <typename T>
auto myFunction(T x, T y) -> std::enable_if_t<isAcceptableType<T, char, std::string, int>>
{
// do something
}
See a demo

Answer 6

People yelling macros are evil are similar to those yelling goto is evil.
Since SFINAE until C++20 is really ugly, macros are a good way to make it more user friendly. But, the macro you provide is indeed bad practice: It's way too long.
I regularly use the following two macros REQUIRES and CONCEPT, named after C++20 concepts, for quite some time already:
#define REQUIRES( ... ) typename std::enable_if< __VA_ARGS__, bool >::type = false
template< typename T > constexpr bool always_true = true;
#define CONCEPT( ... ) always_true< __VA_ARGS__ >
Two notes:
Although the macro actually only take one argument, I use __VA_ARGS__ so that commata are handled correctly when used. Otherwise, people would have to double parenthise expressions involving a comma.
The always_true template is similar to void_t, but I wrote these macros before I knew about void_t.
Usage examples:
template< typename T, REQUIRES( std::is_arithmetic<T>::value && sizeof(T)>=4 ) >
void f( T t );
template< typename T,
REQUIRES( std::is_integral<T>::value ),
REQUIRES( sizeof(T)>=4 ) >
struct BigIntConcept;
template< typename T, REQUIRES( CONCEPT( BigIntConcept<T> ) ) >
void f( T t );
[+] One of the greatest benefits of this macro is: Even people which do not understand SFINAE can read/understand it, but also use it.
[-] The only downside I found so far is: The macros work nearly only for SFINAE in the template-parameter-declaration place (I am sure there is a word for this).