Open rbuckton opened 3 months ago
@waldemarhorwat: Can you clarify as to whether I have accurately described your concerns as presented at the last plenary session? Would you find the NLT inconsistency introduced by (1) a blocking concern for advancement?
Yes, that's a good description of the issue I raised at the meeting.
I'm not in favor of introducing unusual NLT inconsistencies like this.
Would option 2 not be satisfactory? It maintains NLT consistency for all Extractor cases, though is mildly inconsistent with a normal function call. Though there is obvious overlap conceptually, extractors are not the same as calls.
This was originally raised by @waldemarhorwat during the April 2024 TC39 plenary.
The current proposal grammar introduces a parser ambiguity in the following case:
The above example is currently valid JavaScript code that would now be interpreted as an ExtractorBindingPattern.
This specific case can be resolved via a
[no LineTerminator here]
assertion, but @waldemarhorwat expressed concerns about this somehow affecting function calls as well:— Meeting notes - April 11, 2024
My interpretation of this comment is that Waldemar is speaking about "function calls" in the general sense of how the extractor syntax
F(a) = b
shares an (intentional) resemblance to normal function call syntaxF(a)
. If we only introduce the NLT into the ExtractorBindingPattern syntax but not the ExtractorAssignmentPattern syntax, then there is an inconsistency between the two:However, if we introduce an NLT into the ExtractorAssignmentPattern syntax then there is a new ambiguity that is introduced as
is still interpreted as
x(a) = b
, but is not interpreted as an extractor, sincex(a) = b
is already legal JavaScript that currently always throws on assignment since the left-hand side is not a Reference. With this change, it would become an Early Error enforced by static semantics when validating the cover grammar (which we already do for other assignment patterns).As I see it, we have two options:
I should also note there is an additional NLT concern that must also be addressed in addition to the one discussed above:
This would also require an NLT in ExtractorMemberExpression and also possibly an additional production parameter to indicate whether to enforce the NLT depending on the choice of option (1) or (2), above.