In the spec text, clarify which productions may produce Nil, and statically forbid their use in write context

[claudepache]

I intend to update very soon https://claudepache.github.io/es-optional-chaining/ with the following changes:

• Statically identify productions that may produce Nil when evaluated. (Apart of being needed for the next point, this is also useful to make very sure that Nil will not leak where it should not, even in future amendments of the spec.)
• Statically forbid ?. in cases such as a?.b = c, but also a?.b.c[x] = d and delete a?.b().c.

The precise roadmap is:

1. Add a MayProduceNil static semantics rule that will identify productions that may produce Nil when evaluated.
2. Update the IsValidSimpleAssignmentTarget static semantics rule, so that it will return false when MayProduceNil will return false. Together with existing early error rules, that will statically forbid the following cases:
   • in X = Y, when MayProduceNil of X is true;
   • in X *= Y, when MayProduceNil of X is true.
3. Add an early syntax error rule for the following case. (Or not; see Should delete a?.b be allowed or forbidden? #14):
   • in delete X, when MayProduceNil of Xis true.
4. Add few assertions such as “X is not a Nil reference” (because they will be ruled out by the static semantics).

As an aside, this work is orthogonal to #11 (the grammar and static semantics are the same whether Nil is a reference or an abrupt completion).

[rattrayalex]

By Nil, do you mean == null or === null? If the former, it may be useful to define the term at the top. If the latter, null is probably more clear.

[claudepache]

@rattrayalex By Nil, I mean the spec artefact that is used to implement the short-circuiting semantics of optional chaining. As currently specced, it is “the Nil reference”. If #11 is implemented, it will be “an abrupt completion of type Nil”.

Any proposition for a better name is welcome.

[jridgewell]

Why are we forbiding optional assignments?

[claudepache]

Why are we forbiding optional assignments?

Because the semantics of a?.b = c is not obvious and there is no known use case.

[ljharb]

The burden should be on allowing things, not forbidding them.

[jridgewell]

/cc @jdalton

_.get and _.set were some of the most requested (orders of magnitude more than anything else) features of Underscore/lodash. Unfortunately, Github doesn't return helpful results for _.set (it just a query for "set"). A google search shows strong interest, and it's been well established in lodash, and underscore-contrib (it'd be in underscore if it were still active).

[ljharb]

That's a pretty solid use case. It seems tho like this would make a?.b.c = d behave differently from const o = a?.b; o.c = d, which is a concern i share with a few other aspects of this proposal.

If this (the difference between a chain and a separate var) ends up being acceptable tho, then conditional assignment might make sense.

@jridgewell i think a?.b.c = d has obvious semantics; what about a?.b = c? Does that mean if a is nullary, the assignment is skipped?

[claudepache]

Looking at Lodash’s documentation for _.set(), it does not “optional setting”, but “forced-setting” with automatic creation of missing intermediate objects.

What is the expected semantics, and what is the useful one? Optional-setting, forced-setting?

[jridgewell]

Oh man, I'd forgotten about that. Looking at it again, lodash's forced-setting is fraught with edge cases (do primitives get replaced with object? And the array-indices creating an array not an object).

My personal preference would be for optional-setting, but now I'm seeing the complications with forced-setting being expected by some. I think user interest is definitely there, but I'll quietly wait for you to figure out the spec. 😃

[claudepache]

Done. Except that “optional delete” is not forbidden, see #14 (comment) for justification.

If you think that you have sufficiently strong use cases and sufficiently clear semantics for the “optional assignment” case, please open another issue.