dot bracket notation

with the introduction of optional chaining (?.) accessing and invoking a method who's key is a Symbol on a possibly undefined object now includes a dot and bracket:

const personIterator = persons?.[iterator]();

while doing so on a defined object does not include the dot:

const personIterator = persons[iterator]();

I propose supporting the dot to be used with bracket notation without optional chaining:

const personIterator = persons.[iterator]();

This change is opt-in and shouldn't break any existing JavaScript code. It make swapping between optional chaining and chaining a single character change instead of two.

The same could be applied to function invocations (foo.() to complement foo?.()).

I think this could be particularly helpful when building and consuming libraries that make more use of symbols to safely add properties to prototypes without risking name conflicts in the future

I generally don't like introducing multiple identical ways of doing something if it can be avoided. There's a reason style guides try to force a single style upon developers, even if multiple, almost identical paths exist. If we allowed both person.[iterator] and person[iterator] syntaxes, then inevitably everyone will update their style guides to force developers to be consistent with how they do property access within a particular project, and these style guides will likely favor the pre-existing person[iterator] syntax.

4 Likes

The intention is that the ?., not the ? alone, conveys optionality.

The committee decided not to impose the boilerplate tax of obj?..prop, and to instead allow obj?.prop, despite the potential confusion that might cause by being inconsistent with ?.[ and ?.(.

Ah, interesting! To me, it's only the ? that conveys optionality (just like it does in TypeScript on optional properties or parameters), and the . is a necessary evil that's only there to avoid syntactic ambiguity.

1 Like

If a library exposes a groupBy Symbol that is used this way:

persons[groupBy]((person) => person.age);

then I could see some wanting the . because it makes it feel more like calling a method:

persons.[groupBy]((person) => person.age);

or at least that is what I have been told

I did not realize that ?. conveyed optionality and not ? alone; that is interesting… :thinking:

as far as there being multiple ways to do something JavaScript already does this (e.g. double quotes vs. single quotes)

but I tend to agree that less is typically more; in this case it is purely about readability and consistency in writing code using symbols