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

12.2.1 Expression classifications|General #192

Closed
RexJaeschke opened this issue May 21, 2020 · 7 comments
Closed

12.2.1 Expression classifications|General #192

RexJaeschke opened this issue May 21, 2020 · 7 comments
Labels
status: dependency This issue or PR depends on another (see comments) type: bug The Standard does not describe the language as intended or implemented

Comments

@RexJaeschke
Copy link
Contributor

In the list accompanying “An expression is classified as one of the following:”, v5std has

  • A type. An expression with this classification can only appear as the left-hand side of a member_access (§12.7.5). In any other context, an expression classified as a type causes a compile-time error.”

while v6spec has

  • A type. An expression with this classification can only appear as the left hand side of a member_access (Member access), or as an operand for the as operator (The as operator), the is operator (The is operator), or the typeof operator (The typeof operator). In any other context, an expression classified as a type causes a compile-time error.

What to do?

@jskeet
Copy link
Contributor

jskeet commented Jun 22, 2020

I could be missing something here, but I think the standard is right. The is/as/typeof operators are defined using "type" directly rather than using "expression", so we don't need "an expression which is classified as a type" to be valid for their operands.

Proposal: stick with v5, but please validate carefully!

@gafter
Copy link
Member

gafter commented Jun 22, 2020

We should add that it can be the operand of a nameof operation too.

@jskeet
Copy link
Contributor

jskeet commented Jun 24, 2020

Resolution:

  • Leave v5 as it is
  • For v6 we probably want to add nameof, but not the rest of them. (Reasoning: if the operand of nameof is just "expression" in the grammar, it needs to be included here - whereas the others are just "type" in the grammar.)

@RexJaeschke RexJaeschke removed their assignment Jun 25, 2020
@RexJaeschke
Copy link
Contributor Author

2020-06-25 Teleconference:

The v5 spec is correct; no change needed; review for v6.

@jskeet jskeet transferred this issue from another repository Jan 12, 2021
@jskeet jskeet added the type: bug The Standard does not describe the language as intended or implemented label Jan 12, 2021
@RexJaeschke RexJaeschke added the meeting: discuss This issue should be discussed at the next TC49-TG2 meeting label Mar 1, 2021
@jskeet
Copy link
Contributor

jskeet commented Mar 10, 2021

For nameof, this basically depends on the resolution of #10 - once we've firmed up the text there, we can work out whether we need a change here.

@jskeet jskeet added the status: dependency This issue or PR depends on another (see comments) label Mar 11, 2021
@Nigel-Ecma
Copy link
Contributor

By the alternative PR #250, replacing #10, the operand of name is a named_entity and not an expression, so it looks like there is no need for a change here if #250 is accepted.

@Nigel-Ecma
Copy link
Contributor

PR #250 has been accepted (pending @jskeet removing a tuple from an example and creating a PR for v7 to put it back) so there is nothing left to do here. Will close and remove discuss tag.

@Nigel-Ecma Nigel-Ecma removed the meeting: discuss This issue should be discussed at the next TC49-TG2 meeting label May 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: dependency This issue or PR depends on another (see comments) type: bug The Standard does not describe the language as intended or implemented
Projects
None yet
Development

No branches or pull requests

4 participants