Remove old optional chain features

[jridgewell]

• Optional New is removed
• Put operations on an optional chain are removed
• Deletes on optional chain are removed

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/6679/

[jridgewell]

/cc @claudepache

[littledan]

For the deleted paths, what is the behaviour? Is there a syntax error triggered at some point?

Another recent change was to change the scope of short circuiting. For example, (null?.x).y used to return undefined and now it throws a TypeError. Do you have any tests that distinguish these cases?

[jridgewell]

These removals have to be updated in Babylon so tbey’re no longer valid.

[claudepache]

Deletes on optional chain are removed

They are not removed in the official proposal, and I don’t expect them to be removed.

[jridgewell]

I didn’t see it in the spec, where is it handled at?

[claudepache]

I didn’t see it in the spec, where is it handled at?

There is no change needed in the current spec around delete in order to make it work.

[claudepache]

Also, some invalid constructs that should be checked:

The new operator and tagged template literals can no longer be used after optional chaining, e.g.: new a?.b() or a?.b`${x}` : they are not supported by the grammar.

Attempt to assign to an optional chain (e.g. a?.b = 2 or (a?.b)++) is an early Reference Error, in line with what happens with other statically detectable invalid assignment targets. (In the spec text, this is handled by the IsValidSimpleAssignmentTarget static semantics rule returning false.)

[littledan]

A few issues with this patch and the existing optional chaining transform:

• Seems like this expands to == null, but the specified semantics are === undefined || === null. The difference is in the semantics of the document.all object, which passes the test you wrote but not the test in the spec. (== null is fine for loose mode though).
• Should line 13 be deleted as part of getting rid of optional chaining new? Ditto the isNewExpression on line 33.
• I see a bunch of tests deleted; I'd prefer to see them test for the newly intended behavior (and the previous version would fail against the new tests)
• Rather than using the .call method, maybe better to use Function.prototype.call.call (or maybe that doesn't help, I dunno)
• When finding ?. used in places which are disallowed, such as x?.y = z, this should be a SyntaxError because IsValidSimpleAssignmentTarget is false on x?.y. Is this implemented? Ditto for new x?.(y) (though this becomes allowed again, without any chaining semantics, if you add parens like new (x?.(y)).
• I disagree with @claudepache about optional chain delete being good to keep in; we're discussing it at Ban optional chaining delete (and anything else that may be missing?) tc39/proposal-optional-chaining#40 . As long as the spec has optional chaining delete in it, IMO Babel should continue to support it. As things are now, I'd guess that delete x?.y might just consistently evaluate to true without deleting anything; if it is removed, this should become a syntax error.

[claudepache]

As things are now, I'd guess that delete x?.y might just consistently evaluate to true without deleting anything

delete x?.y evaluates to true if x evaluates to null/undefined; otherwise, it evaluates to the same value as delete x.y (with the same side-effect).

[littledan]

that delete x?.y might just

Thanks for clarifying what the specified behavior is. My comment was referring to the Babel source.

[jridgewell]

This has been rebased. To answer a few of @littledan's points:

Seems like this expands to == null, but the specified semantics are === undefined || === null.

This was fixed on master, and is in the rebase.

I see a bunch of tests deleted; I'd prefer to see them test for the newly intended behavior
When finding ?. used in places which are disallowed, such as x?.y = z, this should be a SyntaxError

This would require a large redo of the babylon code to accomplish. I've added checks for AssignmentExpression and UpdateExpression to throw, but they still parse.

As long as the spec has optional chaining delete in it, IMO Babel should continue to support it.

Can someone walk me through how this is handled by the spec? Without it being explicitly called out, I don't see how the current text allows it.

[hzoo]

I think we should land with what's here and make a new PR for new fixes then?

[littledan]

This would require a large redo of the babylon code to accomplish. I've added checks for AssignmentExpression and UpdateExpression to throw, but they still parse.

Sounds like some good follow-on work.

Can someone walk me through how this is handled by the spec? Without it being explicitly called out, I don't see how the current text allows it.

See tc39/proposal-optional-chaining#40 (comment)