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

[expr.type.conv]/2: Priority of first "if", and binding of "otherwise" #1591

Closed
hubert-reinterpretcast opened this issue Mar 30, 2017 · 1 comment
Assignees

Comments

@hubert-reinterpretcast
Copy link
Contributor

In subclause 8.2.3 [expr.type.conv] paragraph 2 of the 2017 DIS, the structure of:

If the initializer is a parenthesized single expression, the type conversion expression is equivalent (in definedness, and if defined in meaning) to the corresponding cast expression ([expr.cast]).
If the type is cv void and the initializer is (), [ ... ].
Otherwise, [an] object is direct-initialized (11.6) with the initializer.

Presents a interpretation where the first sentence is elaborated upon by the latter two as opposed to covering disjoint cases.

Given:

int *f(void *p) {
  typedef int *IntPtr;
  return IntPtr(p);
}

The C-style cast interpretation is valid; however, the direct-initialization is not.
Thus the first sentence conflicts with the latter two under said interpretation.

Furthermore, the parenthetical in the first sentence is meant to be parsed as:

equivalent (in definedness; and if defined, in meaning) to the corresponding cast expression

However, it may be taken as:

equivalent in definedness, should the corresponding cast expression be defined

Suggestion:
Move the latter two sentences under an "Otherwise" bound to the first, with appropriate indentation.
Indent the "then" part of the first as well.

Suggestion:
Improve punctuation within the parenthetical in the first sentence.

@jensmaurer
Copy link
Member

jensmaurer commented Apr 5, 2017

I think starting the second sentence with "Otherwise" already helps: It presents a clear "If ... Otherwise, if ... Otherwise, ..." ladder. Also, simply striking the rather strange parenthetical remark seems not to lose anything and fixes the hostile interpretation issue.

jensmaurer added a commit to jensmaurer/draft that referenced this issue Apr 5, 2017
@jensmaurer jensmaurer self-assigned this Apr 5, 2017
jensmaurer added a commit to jensmaurer/draft that referenced this issue Jul 21, 2017
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