4

Is there a real technical reason it's not allowed

template< class... Ts, class = std::enable_if</*...*/> >
struct S{};

I can't see why the code above is not allowed and the code below is

template< class T1, class T2, class = std::enable_if</*...*/> >
struct S{};
Yakk - Adam Nevraumont
  • 262,606
  • 27
  • 330
  • 524
Hrisip
  • 900
  • 4
  • 13

1 Answers1

3

The C++ standard states that variardic parameter packs must be last (as packs for template classes; for functions, different rules exist).

So in your second case, you don't have a variardic parameter pack. So it is allowed.

If you want to know why the C++ standard states that variardic parameter packs must be last, mostly it is because nobody has given a convincing argument why it should be changed.

By having variardic packs last, the matching rules are going to be simpler (the variardic pack matches everything) and clear. Once you add "oh and you can add defaults" or whatever, wording gets trickier, and what the best choice is gets more confusing.

template<class... Ts, class Tail>
struct foo {};

should foo<int, double> pass double to Tail? Or should it fail? You could spill oceans of ink talking about this.

And what about template specialization? I shudder.

Using this for enable_if stuff is not going to be a strong sell, as concepts are here and solve most if not all enable_if clause issues.

Yakk - Adam Nevraumont
  • 262,606
  • 27
  • 330
  • 524
  • of course `int` and `double` would go into `...Ts`, `Tail` just would be unreachable. And it wouldn't be allowed to have `Tail` to be non-default. Also it's about 2 year to pass to use c++20 – Hrisip Dec 05 '19 at 21:04
  • 1
    @Adler I think the answer tries to explain that what you say would be one valid choice, but not necessarily the only valid one. How to choose? Whatever choosen it would make something complicated even more complicated for comparatively little gain – 463035818_is_not_an_ai Dec 05 '19 at 21:10
  • @formerlyknownas_463035818, I could argue, but I see your point. I'm not to make a point here, all I was hoping for is "a real technical reason", and I guess that's it – Hrisip Dec 05 '19 at 21:22
  • @Adler the real reason is because the standard says so :P – 463035818_is_not_an_ai Dec 05 '19 at 21:23
  • @formerlyknownas_463035818, I'm fond of such answers, like I didn't know that. The standard says many things, some are bad. And I see the community as the driving force and not the commitee(though they do the hard part), and it's good to be aware of the decision reasons (for many reasons). – Hrisip Dec 05 '19 at 21:29