[dcl.ptr] No normative wording prohibiting use of pointer to ref-qualified function type

[ranaanoop]

Full name of submitter: Anoop Rana

Reference (section label): [dcl.ptr]

Issue description: Consider the following program:

template <class Signature>
struct Decompose;

template <class T>
struct Decompose<void(T)> {
    using Type = T;
};

template <class T>
using FTDecay = typename Decompose<void(T)>::Type;

FTDecay<int()&> x{}; //all 3 compilers accepts this although note in dcl.ptr#4 make this ill-formed

Note that int()& is allowed in FTDecay<int()&> as per dcl.fct#10.5

A function type with a cv-qualifier-seq or a ref-qualifier (including a type named by typedef-name ([dcl.typedef], [temp.param])) shall appear only as:

• the type-id of a template-argument for a type-parameter ([temp.arg.type]).

Now, FTDecay<int()&> is int(*)()& because when we wrote FTDecay<int()&> you're explicitly specifying T as the function-type int()&. Next, since a function-type decays to a pointer to a function(in many contexts including this), T will be adjusted to int(*)()&. Thus, void(T) is actually void (int (*)() &) and Type=T is int(*)()&.

But dcl.ptr#4 says:

[Note 1: Forming a pointer to reference type is ill-formed; see [dcl.ref]. Forming a function pointer type is ill-formed if the function type has cv-qualifiers or a ref-qualifier; see [dcl.fct]. Since the address of a bit-field ([class.bit]) cannot be taken, a pointer can never point to a bit-field. — end note]

This seems to make FTDecay<int()&> x{}; ill-formed. But all compilers accept the code Demo. Bug for all the compilers have been reported.

I would also like to suggest to make the note a part of the normative wording to make it more authoritative. Maybe this can be done editorially. Suggested resolution:

Make the note a part of the normative wording.

[jensmaurer]

I think we agree that compilers are buggy here, because the T in the function parameter type decays to a pointer-to-function, at which point a ref-qualified function type is ill-formed.

I think [dcl.fct] is clear enough in this regard: "shall appear only as".

And no, the note is doing the right thing: it's pointing to [dcl.fct], where the normative restriction already appears.

[t3nsor]

The wording of [dcl.fct]/10 is a bit suboptimal in that it refers to both syntactic and non-syntactic constructs, but I agree that there's no doubt that this particular case is ill-formed under the existing wording.

[ranaanoop]

@jensmaurer Btw here gcc bug. Note in the gcc bug, user Marek pointed out that he thinks the program should compile.

[jensmaurer]

I've commented in the gcc bug.