Why do my SFINAE expressions no longer work with GCC 8.2?
Asked Answered
O

3

24

I recently upgraded GCC to 8.2, and most of my SFINAE expressions have stopped working.

The following is somewhat simplified, but demonstrates the problem:

#include <iostream>
#include <type_traits>

class Class {
public:
    template <
        typename U,
        typename std::enable_if<
            std::is_const<typename std::remove_reference<U>::type>::value, int
        >::type...
    >
    void test() {
        std::cout << "Constant" << std::endl;
    }

    template <
        typename U,
        typename std::enable_if<
            !std::is_const<typename std::remove_reference<U>::type>::value, int
        >::type...
    >
    void test() {
        std::cout << "Mutable" << std::endl;
    }
};

int main() {
    Class c;
    c.test<int &>();
    c.test<int const &>();
    return 0;
}

C++ (gcc) – Try It Online

C++ (clang) – Try It Online

Older versions of GCC (unfortunately I don't remember the exact version I had installed previously) as well as Clang compile the above code just fine, but GCC 8.2 gives an error stating:

 : In function 'int main()':
:29:19: error: call of overloaded 'test()' is ambiguous
     c.test();
                   ^
:12:10: note: candidate: 'void Class::test() [with U = int&; typename std::enable_if::type>::value>::type ... = {}]'
     void test() {
          ^~~~
:22:10: note: candidate: 'void Class::test() [with U = int&; typename std::enable_if::type>::value)>::type ... = {}]'
     void test() {
          ^~~~
:30:25: error: call of overloaded 'test()' is ambiguous
     c.test();
                         ^
:12:10: note: candidate: 'void Class::test() [with U = const int&; typename std::enable_if::type>::value>::type ... = {}]'
     void test() {
          ^~~~
:22:10: note: candidate: 'void Class::test() [with U = const int&; typename std::enable_if::type>::value)>::type ... = {}]'
     void test() {

As is usually the case when different compilers and compiler versions handle the same code differently I assume I am invoking undefined behavior. What does the standard have to say about the above code? What am I doing wrong?


Note: The question is not for ways to fix this, there are several that come to mind. The question is why this doesn't work with GCC 8 - is it undefined by the standard, or is it a compiler bug?

Note 2: Since everyone was jumping on the default void type of std::enable_if, I've changed the question to use int instead. The problem remains.

Note 3: GCC bug report created

Olfactory answered 10/8, 2018 at 13:31 Comment(22)
Going by godbolt, it worked as late as gcc 7.3 (and you can see in the assembly that it does the correct thing).Raynold
what are you tying to expand with the ... after ::type ?Richy
What does the ellipsis stands for here? If the condition is true, then there is effectively template <typename U, void...>.Mayonnaise
Good point, that's a relic from simplifying the code. Replacing the default void with int causes the same effect. The original code uses a memberless enum to prevent accidentally specifying a second template paramter.Olfactory
How about removing ellipsis?Finedrawn
Removing ellipsis, replacing the default void by int and adding a default fixes the problem, yes. The real question is, what is it about the above code that worked fine before, but doesn't work any more with GCC 8?Olfactory
More simplified example of the same problem I think: wandbox.org/permlink/xFX6AzuqMB7GSa87.Mayonnaise
Possible duplicate of isn't non-type parameter pack that evaluates to "void..." illegal?Fiduciary
@DanielLangr That one fails in the exact opposite gcc versions as the one in the question...Raynold
@MaxLanghof Sure, but the cause should be the very same.Mayonnaise
@Fiduciary By that question, void... is legal for and only for empty parameter packs, which is exactly what is desired here. Even if it were illegal, replacing the default void with int in the std::enable_ifdoesn't change anything about the question.Olfactory
Minimal example: godbolt.org/g/P9z1pt gcc7.1 OK gcc 8.x KOExhalation
funny, without the second definition: godbolt.org/g/RgwSVJ gcc7.1 KO, gcc 8.x OKExhalation
@Exhalation That's because f in your second example only exists for a constant template parameter.Olfactory
This is weird: godbolt.org/g/mnWcg6 gcc7.1 OK, gcc 8.x OKExhalation
@Olfactory Yes, but f<int> is called!Exhalation
It reaaaaaly looks like a gcc bug.Exhalation
@Exhalation Not quite, the attempt to call f<int> results in an error, since f only exists for e.g. f<const int>. Also, the non-type void... template parameter pack is not the problem - feel free to replace the std::enable_if type from void to e.g. int.Olfactory
@Olfactory that's what strange: on gcc 8.1, f<int>() succeeds. Look: godbolt.org/g/RgwSVJExhalation
@Exhalation Ah yes, sorry, I was only looking at the 7.1 column. Something is definitely strange here... (Clang also gives an error as I would expect).Olfactory
About that specific point, I asked a question here: https://mcmap.net/q/553485/-why-do-my-sfinae-expressions-no-longer-work-with-gcc-8-2/5470596Exhalation
Emm... I think this post is a more proper duplicate, though new versions of the compilers interchange their behaviors, interesting...Fiduciary
A
5

This is my take on it. In short, clang is right and gcc has a regression.

We have according to [temp.deduct]p7:

The substitution occurs in all types and expressions that are used in the function type and in template parameter declarations. [...]

This means that the substitution has to happen whether or not the pack is empty or not. Because we are still in the immediate context, this is SFINAE-able.

Next we have that a variadic parameter is indeed considered an actual template parameter; from [temp.variadic]p1

A template parameter pack is a template parameter that accepts zero or more template arguments.

and [temp.param]p2 says which non-type template parameters are allowed:

A non-type template-parameter shall have one of the following (optionally cv-qualified) types:

  • a type that is literal, has strong structural equality ([class.compare.default]), has no mutable or volatile subobjects, and in which if there is a defaulted member operator<=>, then it is declared public,

  • an lvalue reference type,

  • a type that contains a placeholder type ([dcl.spec.auto]), or

  • a placeholder for a deduced class type ([dcl.type.class.deduct]).

Note that void doesn't fit the bill, your code (as posted) is ill-formed.

Ampulla answered 10/8, 2018 at 16:46 Comment(5)
The problem is not the void default type of std::enable_if! If I understand your answer correctly, SFINAE should work fine for a different type (e.g. int). It doesn't under GCC 8.2.Olfactory
@Olfactory That's why I said in the second sentence "regression if not void" :)Ampulla
Do you mind reducing your answer to that? I've specified int as the type for std::enable_if in the question now, since I really didn't intend to start the discussion of void..., which was originally a relic of my simplifying the code. Note that others come to a different conclusion than you btw: https://mcmap.net/q/583892/-isn-39-t-non-type-parameter-pack-that-evaluates-to-quot-void-quot-illegal :)Olfactory
@Olfactory I don't really understand the answer; thanks thoughAmpulla
@zenn that other answer is incorrect, since this is not a pack expansion. It's merely a nonexpanding template parameter pack which, had you given it a name, could be expanded elsewhere.Maxwellmaxy
M
1

I am not a language lawyer, but cannot the following quote be somehow connected to the problem?

[temp.deduct.type/9]: If Pi is a pack expansion, then the pattern of Pi is compared with each remaining argument in the template argument list of A. Each comparison deduces template arguments for subsequent positions in the template parameter packs expanded by Pi.

It seems to me that since there is no remaining argument in the template argument list, then there no comparison of the pattern (which contains enable_if). If there is no comparison, then there is also no deduction and substitution occurs after deduction I believe. Consequently, if there is no substitution, no SFINAE is applied.

Please correct me if I am wrong. I am not sure whether this particular paragraph applies here, but there are more similar rules regarding pack expansion in [temp.deduct]. Also, this discussion can help someone more experienced to resolve the whole issue: https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/JwZiV2rrX1A.

Mayonnaise answered 10/8, 2018 at 15:13 Comment(1)
Interestingly, that discussion comes to the conclusion that this was a bug in Clang that was subsequently fixed! There seems to be quite a bit of uncertainty about this in the standard...Olfactory
E
0

Partial answer: use typename = typename enable_if<...>, T=0 with different Ts:

#include <iostream>
#include <type_traits>

class Class {
public:
    template <
        typename U,
        typename = typename std::enable_if_t<
            std::is_const<typename std::remove_reference<U>::type>::value
        >, int = 0
    >
    void test() {
        std::cout << "Constant" << std::endl;
    }

    template <
        typename U,
        typename = typename  std::enable_if_t<
            !std::is_const<typename std::remove_reference<U>::type>::value
        >, char = 0
    >
    void test() {
        std::cout << "Mutable" << std::endl;
    }
};

int main() {
    Class c;
    c.test<int &>();
    c.test<int const &>();
    return 0;
}

(demo)

Still trying to figure out what the heck does std::enable_if<...>::type... mean knowing the default type is void.

Exhalation answered 10/8, 2018 at 14:40 Comment(4)
See https://mcmap.net/q/583892/-isn-39-t-non-type-parameter-pack-that-evaluates-to-quot-void-quot-illegal, basically it requires the parameter pack to be empty. Feel free to add int to replace the default void type - that doesn't change anything about the question.Olfactory
@Olfactory Note: without the added tparam (int & char), your two templates functions have the same template signature, hence the ambiguity. What I don't get is why it ever worked before.Exhalation
How so? One of them is template <typename U, void...> and the other is SFINAE, i.e. template <typename U, [error: std::enable_if has no member type]...>.Olfactory
@YSC: typename = std::enable_if_t<cond> requires "strange" extra dummy parameter, better to use std::enable_if_t<cond, int> = 0.Floorman

© 2022 - 2024 — McMap. All rights reserved.