Add proposed feature specification for "implicit names". #4538
Conversation
| * `s!`: If `e` is a `<primary> <selector>*` production where `<selector>*` | ||
| is the single `<selector>` `` `!' ``, and `<primary>` is | ||
| a single identifier expression, then `e` is a single identifier expression | ||
| with the same identifier as the `<primary>`, |
There was a problem hiding this comment.
In the interest of completeness, I'm compelled to ask about (:foo++) and (:foo--) as well.
(I could go either way with them. But I'd lean towards "no".)
There was a problem hiding this comment.
Arguably ... they work and stay within the bounds set out.
The value of foo++ was the value of foo (which has since been incremented).
That means that the meaning of foo-the-parameter is likely the same as foo-the-variable, since the same value is used for both. That's my mental check for whether this makes sense: We write only one name to cover two things, so the name should mean "the same thing" in both uses.
The argument against :foo++ is that we won't allow :++foo, and that asymmetry can be grating.
Or we could allow :++foo too. I'd be perfectly happy with both - they are "one identifier expressions" and the value of the expression is the value of the variable - either what it was before increment, or what it is now, after increment. As long as people don't do patological things with setters. The name is the next identifier in the expression, and it'll be prefixed at most by (s and then at most one ++ or --, the name is easy to find.
And also that if :x++ is allowed, but :x+=1 is not, even if it's definitionally the same, it's a little special-casey. You can use it if you need to add 1, but not if you need to add 2?
But it's a single identifier with the same name and its value is used as the value, so it's not completely out of bounds.
(My biggest argument against cascades is that they contain more identifiers. This one doesn't.
Even if the first one is easy to find, it is still messy. (And more if we'd want :a.b.) Increment expressions don't suffer from that.)
There was a problem hiding this comment.
Or we could allow
:++footoo.
If we did that, then we'd also probably want :-foo, :!foo, and :~foo.
My inclination would to not do any of those. I'd even be OK with not allowing foo!, but I think that one's worth doing because (a) patterns allow it and (b) it makes nullable types easier to work with, which is always good.
There was a problem hiding this comment.
I'd argue against -foo, !foo and ~foo in that they don't mean the same thing as the name. They likely mean the exact opposite.
Doing foo(isOpen: !isOpen) or foo(count: -count) would look wrong, and allowing foo(:!isOpen) and foo(:-count) would hide that.
The only operators allowed are ones that do not change the value of the identifier expression, they just might throw before evaluating to that value (! or as Type).
For id++ and ++id, the value of the expression is the value of the variable, either before or after the variable is incremented, that's why they could be argued to fit. But as I said, a mutable variable is mutable state, being the state can mean something else than just its value. This feature is mainly intended for
forwarding values from one place to another with the same name.
More discussion of other possible syntaxes.
|
Updated, PTAL. |
For issue #3102