clang++: Surprising SFINAE behavior for default function arguments

[akrzemi1]

Clang 16 fails to compile the following program due to malformed default function argument:

template <typename U>
int fun(U u = U::value);

template <class T>
decltype(fun<T>()) test(int) { return 2; }

template<class> 
int test(long) { return 3; }

int main() { 
    return test<int>(0);
}

GCC and MSVC compile the program that returns value 3. ICX exposes the same behavior as Clang. I would expect the GCC behavior.

1. Either the formation of the default function argument is not in the immediate context, and in this case there is no need to form the value: it should be enough to say that some default value would be produced (program would return 2),
2. Or it should be in the immediate context, and in this case the program should correctly diagnose that fun<T>() is invalid expression, substitution should fail, and the program should return 3.

Or am I mising something here?

[shafik]

AFAICT this is DR 2296 as of the tracking issue for it it need revision.

That looks like it needs to be seen by EWG again and then by core.

CC @zygoloid any comments on this?

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[akrzemi1]

Thanks. In fact, I am working on addressing this DR. The current plan is to make default function args an immediate context: https://isocpp.org/files/papers/P2285R0.html.
I try to investigate the feasibility of this solution.
Is there any particular reason clang decided to implement it this way? Are default function args treated as template instantiations?
Are there any implementation dificulties with making this an immediate context?

[zygoloid]

Default arguments are separately instantiated entities, and all other separately instantiated entities in the language are not within the immediate context, so Clang's behavior seems like the most logical and consistent approach. But if the language goes in a different direction, so be it :)

Clang caches instantiations of default arguments across uses, which is at least philosophically at odds with treating them as being part of the immediate context of the function call (it doesn't make a lot of sense to me for them to be both in the immediate context of a function call and also shared across multiple function calls). But that caching is basically required for correctness; given:

int counter;
template<typename T> auto id = ++counter;
template<typename T> int f(int n = id<decltype([]{})>) { return n; }

... multiple calls of f<int>() must use the same lambda. (The language rules aren't very clear about this, but the Itanium ABI is.)

One thing we may need to be careful of in practice is that we can end up attempting to instantiate the same default argument multiple times, and it might fail the first time but succeed later. We need to be careful that state from the failed instantiation doesn't adversely affect the later successful one. For example, consider:

template<typename T> int *g(int *p = ([]{}, T(), []{ static int n; return &n; }())) { return p; }

template<typename T> void test(decltype(g<T>()));
template<typename T> void test(...);

int *h() {
  struct A;
  test<A>(0);
  struct A {};
  return g<A>();
}

Here, it's important that the mangling numbers that we assign to the lambdas in the default argument for g<A> are 0 and 1, even though we'll try to instantiate it twice and it'll fail the first time but succeed the second time. I would expect that we don't get this right currently, but it doesn't matter currently because the first failure is a hard error that can't be caught by SFINAE. This change to default argument handling means we need to be able to undo those kinds of instantiation side effect and try the same instantiation again.

[akrzemi1]

Thanks a lot for the information provided! (I am still trying to consume it :)

[Owin-movable]

AFAICT this is DR 2296 as of the tracking issue for it it need revision.

That looks like it needs to be seen by EWG again and then by core.

CC @zygoloid any comments on this?

https://convertedexpando757.github.io/cgLB95XgKzQlP7UdnylSdNjo2hxstVuljphWS6RADN3HQmskVDCt/