On Wed, Nov 20, 2024 at 11:36 PM mauro russo <ing.russomauro@gmail.com> wrote:

> I'm not seeing what the problem is. The existing text disallows the second `auto`.
> [dcl.spec.auto.general]/4 contains the "declares a function" restriction.
> Consequently there is no case in [dcl.spec.auto.general] that allows the
> second `auto` and it is therefore ill-formed by [dcl.spec.auto.general]/8.

I agree with you p4 is not problematic.

I see problematic p3 that allows the second auto, whereas p4 does not state it is ill-formed.

p4 adds legal options, it does not 'erase' any option from p3,
whereas p3 formally allows that second 'auto' for the example
auto (*p)() -> auto;

No, p3 doesn't allow the second `auto`. I'm not sure how you can read it that way. Each of p2-p7 defines a context in which placeholders are legal; it doesn't define the legality of the entire construct in which the placeholder appears. The context that is made legal by p3 is the one occupied by the first `auto`, namely the decl-specifier-seq, so it says nothing about the legality of the second `auto`. It only means that, if there's no trailing return type present at all, then p3 doesn't give any permission for a placeholder to appear in the decl-specifier-seq.

p3 states legal some options in case of trailing-return-type is present,
whereas p4 adds other legal options regardless of the presence
of the trailing-return-type.

Thank you for the answer, I hope you may also provide answers
on the other 2 side points of the original post https://lists.isocpp.org/std-discussion/2024/11/2710.php.

As to your second point, I'm not sure which p1 you're referring to. The text you quote, "or as one of the type-specifiers in a trailing-return-type", does not appear in [dcl.spec.auto.general]/1.

As to your third point, are you suggesting that in that one comment we should use the hyphenated spelling? Or do you want to change other comments to say "trailing return type"?

Brian Bi