double dot syntax proposal

[victornpb]

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..c

and since .[ is syntax error

foo.['bar']..a.['c']

a.['b'].['c']..d

pros:

• 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

[ljharb]

That would mean we'd have ., .., and ..., all doing different things, and only a keystroke apart. Seems confusing to me.

[rinick]

e4x use double dot operator, although it's deprecated, it's probably still not the time to introduce a syntax conflict with that

[Mouvedia]

For the record in E4X "the .. operator accesses all children no matter how deeply nested".

[claudepache]

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.

[claudepache]

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.)

[victornpb]

@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

[Zarel]

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 ?.

[Mouvedia]

The .. token has historically meant "range" in other languages, and not much else

You are right, that's the clincher.

[nodkz]

@littledan maybe close this issue?

[victornpb]

I agree