thanks for the answers, I will reply here for both posts of your answers :

> I'm not sure what your remaining question is, then. Can you give an
example?

don't mind, it was a comment stating that
I was on the same page since the original post.


>> About p2, ....
>> a) ... another possible interpretation might be "The type of" (one
>> of the three cases),
>> that is, applying parameter declaration only to the function
>> declaration.
>> Do you believe the text may be clarified to avoid such ambiguity ?

> Well, the alternative interpretation is absurd, because you don't get to
declare
> the type of a lambda. But, ideally, it should be possible to parse the
sentence
> without needing semantic knowledge about C++, so, yes, I think this should
> be clarified.
> I think this would be an editorial-level change, so please submit an
> issue here: https://github.com/cplusplus/draft/issues
> And attach a pull request, if you can.

ok, I will. I differently supposed I should have written an email
to wg21bot_at_[hidden] in these cases,
as indicated in https://isocpp.org/std/submit-issue.

Just as a parenthesis: who to get an answer from, for
this warning ? -> (https://lists.isocpp.org/std-discussion/current/2673.php)



>> Does it affect the way a trailing-return-type may be in place ?

> I'm not understanding the question.

Don't mind, the other parts of your answer were enough. Thank you.


>> b) do you believe that the words 'see below' in the p2 statement
>> ... are still applicable ?
>> ...

> The "see below" in p2 refers to p3. To understand what it means,
> notice that we have the same language in p5, except without "see below"
> since it's not a forward reference from p5. We have this example:
> auto (*fp)() -> auto = f; // OK

ok, it means my original example (original post)
"auto (*p)() -> auto; // ill-formed"
was more related to p5, instead, with a missing initializer.
(no answer needed for this comment)

> The second `auto` is in "the trailing-return-type that specifies the type
> that replaces" the first `auto`.

Yes, this has always been clear. Indeed, one of my focus was about
redundancy compared to [dcl.fct]-p(1.3).
(no answer needed for this comment)


> You can have this in a parameter declaration too:

> constexpr auto l = [](auto (*fp)() -> auto) { return fp; };
> int foo();
> static_assert(l(foo) == foo);

> Note that GCC currently ICEs on this example, but Clang and MSVC are ok
with it.

Based on all above, I still have feeling of improvements needed.
I have to admit not to be sure about 'function declarator' right now,
even due to this conversation.
It should be whatever match the sequence stated in [dcl.fct]-p1.
Anyway, I will still try to explain my residual doubts
about [dcl.spec.auto.general] :

p2: states that 'optionally_constrainted auto' may be in a decl-specifiers
doubt A) -> it might better specify that it is intended for the parameter,
    e.g., not for a nested parameter within the function type of the
    initial parameter:
    void func(int (*pf)(auto p2) );
    as this would mimic a kind of template template paramer (based
    on the well clear Note 1 of p2), which is not an object.
    (just an additional comment:)
    In this perspective, I re-evaluate as good the part
    "that specifies the type that replaces such a decl-specifier"
    as it avoids thinking to other more nested trailings.

p2: states that 'optionally_constrainted auto' may also be in a
type-specifier
      for a trailing-return-type but only if this replaces a decl-specifier
      that in turn contains a similar 'auto'.
      (I don't dare now to think about different constraints for the two
'auto'
       occurrences , I will study this case, maybe both constraints apply,
       maybe the first in decl cannot be constrained if also the second
exists)
doubt B) -> why there is need to refer p3 ? Indeed, p3 does not rule out
     any case as exception compared to previous (or next) statements.
     It seems me that p3 just generalizes the option to use 'auto'
     in decl-specifier for any function declarator (but adding the
     constraint to have a trail, which does not apply to function
     parameters, nor to function pointer variables):
     ... not only for parameters, if (here, my ignorance) function
declarators
         include the case of parameters,
         otherwise there would be no relation at all with p2,
         but in both perspectives why the relation 'see below'
         is needed from p2 ?
     Indeed, the following code (elaborating your examples) works,
     but I see it works based only on p2 and p5, regardless of p3.

int f1(int){return 0;}
// based on p5, without trail that p3 would require, instead
auto (*pf1)(int) = f1;

// based on p2, without trail that p3 would require, instead
void f2(auto (*)());

// based on p2, without trail that p3 would require, instead
auto l3 = [](auto (*fp)()) {return fp; };
int f3(){return 0;};
auto* v3 = l3(f3); // based on p5


Other working code comes, instead, from p3:
auto (*pf)() -> int;
Indeed, p5 would not allow this, as p5 requires an initializer,
(no answer required here, unless I am wrong)

Or the following, from p4, requiring to declare a function.
auto foo() -> auto;
Here, there is no parameter, no variable, therefore
only p4 applies.
(no answer required here, unless I am wrong)

doubt C) -> Would it be the case of adding a short
list of examples, to cover also other parts, not only
specific to p5 ?



>> trailing return type -> trailing-return-type
>> in [class.conv.fct]-p3

> My preference is to change the comments to say "trailing return type"
> since they're referring to the use of the feature, not the fact that the
> grammar production is present (although, of course, it doesn't make
> a difference, since the two situations are the > same). But, that's just
my opinion.

That would be for sure also my preference but, as highlighted in the
original post,
I have checked that in all other examples dashes are present.
In this case, unfortunately, I don't have a way to check in the current
draft,
but in the last pdf draft before C++23 it is a unique case.


About the question on [dcl.type.auto.deduct]-p3,
I will open a proper separated thread to report
the full topic.

Thank you.

>