Add proposed feature specification for "implicit names". #4538
Conversation
| return (:red, :green, :blue, :alpha); | ||
| } | ||
| } | ||
| ``` |
There was a problem hiding this comment.
It may be worth noting that the following would suffice. Before:
extension on Color {
Color withAlpha(int alpha) =>
(red: red, green: green, blue: blue, alpha: alpha);
}alpha is resolved in the lexical scope, and the other identifier expressions are resolved as instance member references (adding this.). After:
extension on Color {
Color withAlpha(int alpha) => (:red, :green, :blue, :alpha);
}
}If you want to avoid the discussion about "but is that readable?" then perhaps use plain local declarations rather than an extension method.
|
|
||
| As a non-grammatical restriction, it's a **compile-time error** | ||
| if a `<namedExpression>` omits the leading`<identifier>`, and the following | ||
| expressions is not a _single identifier expression_, as defined below. |
There was a problem hiding this comment.
Typo:
| expressions is not a _single identifier expression_, as defined below. | |
| expression is not a _single identifier expression_, as defined below. |
| if a `<namedExpression>` omits the leading`<identifier>`, and the following | ||
| expressions is not a _single identifier expression_, as defined below. | ||
|
|
||
| In short, an expression is a _single identifier expression_ |
There was a problem hiding this comment.
| In short, an expression is a _single identifier expression_ | |
| An expression is a _single identifier expression with identifier_ |
Having seen line 93, it seems likely that this paragraph should be commentary (such that readers will know which one wins if the two definitions disagree). Moreover, if this is changed to commentary then it would probably be more readable if placed after the actual definition (which would then motivate a reintroduction of 'In short,')
| expressions is not a _single identifier expression_, as defined below. | ||
|
|
||
| In short, an expression is a _single identifier expression_ | ||
| which has a specific single _identifier_ if and only if |
There was a problem hiding this comment.
| which has a specific single _identifier_ if and only if | |
| `id` if and only if |
| which has a specific single _identifier_ if and only if | ||
| it is one of the following: | ||
| * An identifier, with that identifier. | ||
| * `s!`, `s as T`, `(s)`, `s..cascadeSection`/`s?..cascadeSection` |
There was a problem hiding this comment.
| * `s!`, `s as T`, `(s)`, `s..cascadeSection`/`s?..cascadeSection` | |
| * `s!`, `s as T`, `(s)`, `s..cascadeSection`, and `s?..cascadeSection` |
I think this works fine, but it might be helpful to mention (or show in an example) that this admits constructs like id?..m1()..m2() because id?..m1() can play the role as s.
| where `s` is a single identifier expression, | ||
| and then it has the same identifier as `s`. | ||
|
|
||
| More formally, An expression `e` is a single identifier expression with a certain identifier if and only if it is defined as such by the following: |
There was a problem hiding this comment.
| More formally, An expression `e` is a single identifier expression with a certain identifier if and only if it is defined as such by the following: | |
| An expression `e` is a single identifier expression with a certain identifier if and only if it is defined as such by the following: |
| then `e` is a single identifier expression with the same identifier as | ||
| the `<conditionalExpression>`. | ||
|
|
||
| The _name of a named expression_ is then: |
There was a problem hiding this comment.
In this particular case it's probably more readable to keep using the actual non-terminal:
| The _name of a named expression_ is then: | |
| The _name of a_ `<namedExpression>` is then: |
| The name of a `<namedArgument>` or a named `<recordField>` is the name of | ||
| its `<namedExpression>`. | ||
|
|
||
|
|
| it now uses this definition of the name of a `<namedArgument>`. | ||
|
|
||
| Where the Record specification for a record literal refers to a field name, | ||
| it now uses to this definition. |
There was a problem hiding this comment.
Typo:
| it now uses to this definition. | |
| it now uses this definition. |
| The identifier expression can be wrapped in casts `!` or `as T`, in parentheses, | ||
| or can be pre-used/modified using cascade invocations, but none of those | ||
| operations change the value from evaluating the identifier, only, potentially, | ||
| whether it evaluates to a value at all. |
There was a problem hiding this comment.
Perhaps mention prefixed names, and motivate why they aren't included: (name: p.name,) can't be abbreviated to (:p.name,). Presumably it's motivated by the need to insist on "first" in "the name is the first identifier after the colon".
There was a problem hiding this comment.
Not sure why a prefixed name is more relevant to mention than, say, a static member or an instance member.
(And "first identifier" is the reason. I'd personally be happy to allow any prefix.id or typeName.id, expression.id or expression?.id, so that's probably why I'm not trying to find an argument for why we don't allow it.)
2 participants
For issue #3102