Description
Based on the discussion starting with https://lists.isocpp.org/std-discussion/2024/11/2710.php,
I resulted with some changes to propose for the text, as follows:
1) in p2, the verbal form
The type of a parameter-declaration of a function declaration, lambda-expression, or template-
parameter ...
may be ambiguous in the sense that it may be interpreted both as the type of any of three things (incorrect) or the type of a parameter of any of three things (correct).
In the discussion on std-discussion, it was highlighted that the former interpretation does not make sense as a lambda expression has never an explicit type, however it was still agreed that the verbal syntax should be improved (https://lists.isocpp.org/std-discussion/2024/11/2724.php).
Corresponding change proposed through PR #7450 is:
The type of a parameter-declaration of one of the following three: a function declaration, lambda-expression, or template-
parameter, ...
=> approved in a different form (see PR #7450)
2) in p2, both occurrences of template-parameter may be improved as non-type template-parameter.
Corresponding change has been proposed through PR #7452.
I see this is a minor change, not strictly necessary.
=> agreed rejection (see PR #7452)
3) in p2, the part
can be declared using a placeholder-type-specifier
might be interpreted in a too general way, as possibly using a placeholder even for a nested parameter in case of the primary parameter has function pointer type.
A proposal to avoid such potential ambiguity is to specify that in case of function pointer type, then only the trailing-return-type may get a (further) placeholder. The fact that this trailing is the one that replaces the type specified by the aforementioned decl-specifiers, assure to make impossible the interpretation of applying a placeholder to nested parameters.
Corresponding change proposed through PR #7454 is:
from: ... or as one of the type-specifier s in a trailing-return-type that specifies the type that replaces such a decl-specifier ...
to: ... or, in case of function pointer type, as one of the type-specifier s in a trailing-return-type that specifies the type that replaces such a decl-specifier ...
For consistency, the same addition is proposed to be also in p5.
=> required a different form (see PR #7454) in order to include also function reference types.
=> agreed rejection (see PR #7454)
4) in p2, the part
...(see below)...
seems not to make sense (anymore?), as agreed on std-discussion (https://lists.isocpp.org/std-discussion/2024/11/2738.php)
It seems it was a reference toward p3 but, by then, p3 does not remove or add any option for the case of a parameter having a function pointer type.
I suppose it cannot even be a reference toward examples.
Corresponding change has been proposed through PR #7455.
5) in p5, there are several examples [Example 1], covering p5, p3 and, partially ,p4.
I guess few other examples may be added to cover also p2 and, fully, p4.
And, maybe, it would be better to have Example 1 as a separated part, as inside p5 seems it should cover only p5.
Corresponding change has been proposed through PR #7456.
6) developing further the point 4) above, it would be likely better to have current part 3 before current part 2. Indeed, p3 specifies a general rule on function declarators, whereas p2, p4, p5, are then specific for parameters, functions, and variables, respectively.
In case this proposal is acceptable, I am not sure whether to get also current part 4 (for function declarations) before current part 2 as well. Indeed, both p2 and p5 replicate the reference to a trailing-return-type.
No PR created yet for this point.
7) last point is about a typo. In [class.conv.fct]-p3 there is the unique case when the form trailing return type is used without dashes (i.e., not trailing-return-type) over all the standard, regardless of being in code snippets or not. Maybe, it makes sense to be consistent by adding dashes.
No PR created yet for this point.