double dot syntax proposal
victornpb opened this issue · 20 comments
Just a wild idea, after more than a year revisiting this:
Double dot .. is syntax error, so it could be possible to allow this syntax and avoid the problems with the ? character:
foo..bar.baz
obj.a..b..cand since .[ is syntax error
foo.['bar']..a.['c']
a.['b'].['c']..dpros:
- Clean
- Not much different than the original dot accessor, but at the same time visually distinguishable.
- Somewhat consistent with
==and the variant===(but opposite)
cons:
- Not alike other languages�
- somewhat misleading to mathematical
..
Another variant on the same idea is to use:
a,.b,.c,.d
I don't know it this would be ambiguous for the parser along with other structures tho
That would mean we'd have ., .., and ..., all doing different things, and only a keystroke apart. Seems confusing to me.
e4x use double dot operator, although it's deprecated, it's probably still not the time to introduce a syntax conflict with that
For the record in E4X "the .. operator accesses all children no matter how deeply nested".
e4x use double dot operator, although it's deprecated, it's probably still not the time to introduce a syntax conflict with that
For information, E4X was removed from Firefox (the only web browser that supported it) about 6 years ago.
That would mean we'd have
.,.., and..., all doing different things, and only a keystroke apart. Seems confusing to me.
There is no confusion possible with ..., because it is used in a different syntactical context. We have even several instances of the same token meaning completely different things, (e.g., ( ) for grouping and for function invocation, / for division and for regexp literals), and this is not confusing because they are used in mutually exclusive contexts (except in one edge case related to defective ASI).
By contrast, = and == meaning two wildly different things is problematic (and a source of bugs), because they can be used in the same context.
I don’t think that the difference between . and .. is much more (or less) confusing than the difference between == and ===. Or, well, between . and .. in late E4X.
(Also, before someone else wastes a comment for it: The fact that 4..x is already valid today with the meaning of (4.).x is a non-issue, because (4)..x and (4.).x will have exactly the same effect.)
@claudepache Those are really good points!
The real issue is that we already used all symbols on a standard US keyboard, everything from now on will either lack ergonomics or visual clarity
That’s a better point, thanks - it would not be web compatible to change the meaning of 4..foo, as that must always non-optionally look up foo on Number.prototype with a receiver of 4, and having a..b do something different would be very confusing.
it would not be web compatible to change the meaning of
4..foo, as that must always non-optionally look up foo on Number.prototype with a receiver of 4, and havinga..bdo something different would be very confusing.
Why would it be confusing, since it would not be observable? If one wants to be pedantic, one can say that the programmer did write (4)..foo, but the engine (or the spec) optimised it to (4.).foo because it can be proven that there is no observable difference.
My real objection here is that this is unpopular, because we already voted (in #51) on what we prefer, and a?.b a?.[b] a?.(b) was our first choice, and no other choice received positive votes, and now that the committee has finally agreed to implement our first choice, considering other choices would set us back very far.
Other reasons to prefer a?.b over a..b:
?.is what every other language uses- The
?character makes sense to be associated with optionals - The
..token is even more difficult to extend to optional call and optional dynamic property access - The
..token has historically meant "range" in other languages, and not much else
If we were starting from scratch, it'd be an interesting proposal, but I just see no reason to reconsider ?.
@claudepache because of 4..foo.bar no longer throwing an error, and instead returning a value, i suspect it would break things. Obviously we’d need data.
@ljharb Why would 4..foo.bar no longer throw an error?
@claudepache because the optional access on 4.foo would shortcircuit the .bar access that would normally throw on undefined - unless I’m misunderstanding something
@ljharb I think you’re confused. There is no optional access of bar on 4..foo, the (non-)optional access is on 4.
@claudepache in the actual proposal yes, but I’m talking about based on the suggestion in this issue thread to make .. optional.
@ljharb I also think you're confused. 4?.foo.bar would throw an error in the current proposal, because it desugars to (4 ?? {}).foo.bar, which is still an error.
@ljharb: you are confused, it would throw. The “optional” part is the 4, not the .foo prop.
@jridgewell @Zarel ahhh thanks for helping me see that. I’ll hide my comments and the related responses.
The
..token has historically meant "range" in other languages, and not much else
You are right, that's the clincher.
@littledan maybe close this issue?
I agree