Description
Full name of submitter (unless configured in github; will be published with the issue): Jim X
[temp.param.note] p3 says:
[Note 3: If an id-expression names a non-type non-reference template-parameter, then it is a prvalue if it has non-class type.
Otherwise, if it is of class type T, it is an lvalue and has type const T ([expr.prim.id.unqual]). — end note]
Then, in [expr.prim.id.unqual], there is still only a note that says the type of the id-expression, [expr.prim.id.unqual.note] p4
[Note 4: If the entity is a template parameter object for a template parameter of type T ([temp.param]), the type of the expression is const T. — end note]
If there is no extra formal rule, then [temp.param] p8 just trumps any note, which says:
An id-expression naming a non-type template-parameter of class type T denotes a static storage duration object of
T is the declared type of the id-expression.
Suggested Resolution
When an id-expression that denotes the template parameter object appears in a context other than decltype(id-expression) , we should define its type with a formal rule.
In this decltype(id-expression), GCC and Clang have divergence, GCC says the type is const T while Clang says it is T.
struct A{};
template<auto const a>
void show(){
decltype(a) b;
A& rf = b;
}
int main(){
show<A{}>();
}