explicit template instantiation wrongly checks decomposition of private members

[schaumb]

The following code does not compile:

template<class T, class Mb>
struct First { void f(); };

struct A {
    A();
private:
    int a; // probably not this easy to calculate the first member's type.
    int b;
}; 


// compilation unit 1
A::A() {
    // can use decomposition
    First<A, decltype(+[] (A &v) -> decltype(auto) { auto& [x, y] = v; return x; })> f1; 
    f1.f();
}


// compilation unit 2
template<class T, class Mb>
void First<T, Mb>::f() {}

template struct First<A, decltype(+[] (A &v) -> decltype(auto) { auto& [x, y] = v; return x; })>; // error

It should based on the C++ standard: https://eel.is/c++draft/temp.spec#general-6

<source>:25:73: error: cannot decompose private member 'a' of 'A'
   25 | template struct First<A, decltype(+[] (A &v) -> decltype(auto) { auto& [x, y] = v; return x; })>;

godbolt

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Bela Schaum (schaumb)

The following code does not compile:

template<class T, class Mb>
struct First { void f(); };

struct A {
    A();
private:
    int a; // probably not this easy to calculate the first member's type.
    int b;
}; 


// compilation unit 1
A::A() {
    // can use decomposition
    First<A, decltype(+[] (A &v) -> decltype(auto) { auto& [x, y] = v; return x; })> f1; 
    f1.f();
}


// compilation unit 2
template<class T, class Mb>
void First<T, Mb>::f() {}

template struct First<A, decltype(+[] (A &v) -> decltype(auto) { auto& [x, y] = v; return x; })>; // error

It should based on the C++ standard: https://eel.is/c++draft/temp.spec#general-6

<source>:25:73: error: cannot decompose private member 'a' of 'A'
   25 | template struct First<A, decltype(+[] (A &v) -> decltype(auto) { auto& [x, y] = v; return x; })>;

godbolt

[shafik]

Note no implementation accepts this code as well-formed: https://godbolt.org/z/x5brEYsW4

and this is expected as per dcl.struct.bind p5 which says:

Otherwise, all of E's non-static data members shall be direct members of E or of the same base class of E, well-formed when named as e.name in the context of the structured binding ...

v.a is not well-formed in this context since it is private and not accessible. In the first case it is within a member of A and this accessible.

[schaumb]

@shafik
I disagree with this argument, because v.a is well formed, see that this is compiling:

// compilation unit 1
A::A() {
    First<A, decltype(+[] (A &v) -> decltype(auto) { return v.a; })> f1;
    f1.f();
}

// compilation unit 2
template<class T, class Mb>
void First<T, Mb>::f() {}

template struct First<A, decltype(+[] (A &v) -> decltype(auto) { return v.a; })>;

As I linked, The usual access checking rules do not apply to names in a declaration of an explicit instantiation or explicit specialization

Please reopen the issue.

[shafik]

CC @zygoloid do you believe this was meant to be supported?

It looks like it came in via: https://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0692r1.html

but it is pretty bare bones wrt examples.

The second examples the OP provided has mixed support: https://godbolt.org/z/1v4zq5a3T

[schaumb]

Gcc has another problem: it cannot accept lambdas as template instantiation, but when lambda is not at the declaration level, it accepts it.

msvc has many other bugs with the template instantiation, as this and this

[schaumb]

@shafik can you reopen it until a final decision is made?