Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarifications in [dcl.spec.auto.general] #7453

Open
mrussoLuxoft opened this issue Nov 27, 2024 · 2 comments
Open

Clarifications in [dcl.spec.auto.general] #7453

mrussoLuxoft opened this issue Nov 27, 2024 · 2 comments

Comments

@mrussoLuxoft
Copy link
Contributor

mrussoLuxoft commented Nov 27, 2024

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.

@jensmaurer
Copy link
Member

For the third change, do you have an example that highlights the difference?

@mrussoLuxoft
Copy link
Contributor Author

mrussoLuxoft commented Nov 27, 2024

yes, an example for the third point is:

void foo(int (*)(auto));

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants