On Fri, Nov 22, 2024 at 8:54 AM mauro russo <ing.russomauro_at_[hidden]>
wrote:

> 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)
>

I imagine Herb Sutter (herb.sutter_at_[hidden]) either can edit that page or
knows who can edit it.


>
>
>
> >> 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.
>

If you have a concrete wording suggestion, please open an issue at
https://github.com/cplusplus/CWG/issues so CWG can discuss it.


>
> 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.
>

I suppose "(see below)" may not be strictly needed. Or perhaps there is a
reason for it that I'm not aware of.


> 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 ?
>
> It appears that the examples already cover p3 and p4. Are you requesting
examples for p2?


>
>
> >> 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.
>
>>

-- 
*Brian Bi*