9

Consider the following program:

template <class T> struct A { using X = typename T::X; };
template <class T, typename A<T>::X* = nullptr> void f(T, int);
void f(...);
template <class T> void g(T, int, typename A<T>::X* = nullptr); // #
void g(...);

int main() {
  // f(0, nullptr); // error
  g(0, nullptr); // ok       
}

g(0, nullptr) compiles while f(0, nullptr) does not (tested under GCC trunk and Clang trunk on Godbolt). It seems that during the template argument deduction process of #, the compiler does not instantiate A<int> when it finds the argument nullptr does not match the parameter int. Where does the standard specify this behavior?

xskxzr
  • 12,442
  • 12
  • 37
  • 77
  • 1
    MSVC fails on both. EDG compiles both. :( – Rakete1111 Oct 27 '18 at 18:16
  • 1
    So basically this is a SFINAE question, and the core issue is which part of template instantiation is covered under "Substitution Failure". Does the unnamed defaulted template argument in `f` cause a substitution failure? – MSalters Oct 27 '18 at 18:22
  • @MSalters I think neither is substitution failure (I use `A::X` rather than `T::X` to try to avoid substitution failure). If you delete the `int` parameter and call it like `g(0)`, then both GCC and Clang reject the code. – xskxzr Oct 27 '18 at 18:30
  • My g++ (6.3.0) compiles both; my clang++ (3.8.1) fail on both. Gosh. – max66 Oct 27 '18 at 18:30
  • @xskxzr: That sounds reasonable - substitution failure would reduce the overload sets to just `f(...)` and `g(...)` respectively, which means any form would be acceptable. That's the point of SFINAE - it silently removes potential overloads that would be ill-formed. – MSalters Oct 27 '18 at 18:38

2 Answers2

4

This is CWG1391:

If deduction succeeds for all parameters that contain template-parameters that participate in template argument deduction, and all template arguments are explicitly specified, deduced, or obtained from default template arguments, remaining parameters are then compared with the corresponding arguments. For each remaining parameter P with a type that was non-dependent before substitution of any explicitly-specified template arguments, if the corresponding argument A cannot be implicitly converted to P, deduction fails.

T.C.
  • 133,968
  • 17
  • 288
  • 421
  • So do you mean it is a bug that `f(0, nullptr)` is rejected? – xskxzr Oct 28 '18 at 05:56
  • So this step should be performed before substitution of deduced template parameter? But for `f` substitution must be performed in the second template parameter to get its argument. So this paragraph would not apply to `f`. So I expected this paragraph not to apply to `f` even in [this case](https://godbolt.org/z/8aefh1). But both gcc and clang accept this code. Is the substitution of deduced template arguments performed in two steps: before application of this paragraph, substitution is performed in the template parameter; after this paragraph, substitution is performed in the function type? – Oliv Oct 28 '18 at 08:28
3

It is possible that you are bitten by DR #1844. In [temp.deduct]/8 it states:

If a substitution results in an invalid type or expression, type deduction fails. An invalid type or expression is one that would be ill-formed, with a diagnostic required, if written using the substituted arguments. [ Note: If no diagnostic is required, the program is still ill-formed. Access checking is done as part of the substitution process. — end note] Only invalid types and expressions in the immediate context of the function type, its template parameter types, and its explicit-specifier can result in a deduction failure. [ Note: The substitution into types and expressions can result in effects such as the instantiation of class template specializations and/or function template specializations, the generation of implicitly-defined functions, etc. Such effects are not in the “immediate context” and can result in the program being ill-formed. — end note ]

The problem here is that "immediate context" is not really given a definition, leading to variance among compilers.

user10568656
  • 31
  • 1
  • 2
    I think there is no reason for a specific compiler to treat `A::X` in `f` as not an immediate context, but to treat that in `g` as an immediate context. So why is there a difference between the behaviors for `f` and `g`? – xskxzr Oct 28 '18 at 03:48