Does NTTP construction always happen for CTAD even if value of type of that specialization is given?

Question

This is (partially) reduced from CTAD instantiates other specialization when explicit argument is given.

https://godbolt.org/z/5To7nKEP3

template<int N>
struct Bar {
    int n = N;
    constexpr Bar() {}
    constexpr Bar(const Bar& b): n{b.n - 1} {}
};

template<Bar b> constexpr int get_n() { return b.n; }

constexpr auto b = Bar<1>{};
static_assert(b.n == 1);

#ifdef _MSC_VER
static_assert(get_n<b>() == 1);
#else
static_assert(get_n<b>() == 0);
#endif

Clang and GCC seems always invoke and deduce from Bar's constructor(s) to determine the real template argument even if the given argument is of type of specialization of Bar, which MSVC doesn't agree.

What does the standard say?

Answer 1

The program should be ill-formed for either of the static_asserts.

First, note that this has nothing to do with CTAD. If you explicitly specify Bar<1> as template parameter type, you still get the same compiler behavior.

Class template argument deduction is always done and will deduce Bar<1> here.

However, the question is now how the template parameter object is initialized from the template argument to determine the relevant specialization of get_n that will be called.

How exactly this is supposed to happen for class types was underspecified, see CWG issue 2459. I guess this is why you see compiler divergence in your example.

The resolution of the issue with paper P2308R1 at the end of 2023 makes it so that the call get_n<b>() will be ill-formed.

Basically, the new rules state, applied to your example, that we start by imagining a variable defined as

constexpr Bar<1> v = b;

And then we further imagine that the template parameter object (also of type Bar<1> as deduced earlier) is copy-initialized from the expression v. If then the the template parameter object is not template-argument-equivalent to v (i.e. they have the "same" value (and type)), then the program is ill-formed.

That happens in your case, because the copy constructor (which is used in the initialization of v and in the copy-initialization of the template parameter object) will produce a different value in the new object than in the source object.

It seems that none of the compilers have implemented that yet.