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