You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
A function declaration with a parameter which has function pointer type.
To define the type of the parameter we are "using" a placeholder type, but it is a decl-specifier related to a nested parameter.
Such a code is clearly illegal, it would mimic a template template parameter.
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.
The text was updated successfully, but these errors were encountered: