Should we include “optional property assignment” a?.b = c

[claudepache]

For the most general case illustrating short-circuiting, the instruction:

a?.b.c().d = e;

is equivalent to:

if (a != null)
    a.b.c().d = e;

@alangpierce has found real-world usages of that form in CoffeeScript, some of them seem reasonable, including two-level deep chains a?.b.c = d:
https://gist.github.com/alangpierce/34b7aa40cda51b0a089a44680bdfed7e

Should we include that? In particular, are the semantics clear enough? There are the following subcases:

• simple assignment: a?.b = c
• combined assignment: a?.b += c, a?.b >>= c, etc.
• increment/decrement: a?.b++, --a?.b, etc.
• destructuring assignment: { x: a?.b } = c, [ a?.b ] = c, etc.
• for-in/of loop header: for (a?.b in c), for (a?.b of c)

[alangpierce]

Another question is whether this code should evaluate c() if a is null:

a?.b = c()

In CoffeeScript, it skips the evaluation of c() if a is null. In other words, the short-circuiting extends all the way up to assignment operations. But an alternate interpretation is that a?.b evaluates to a writable reference that does nothing when you assign to it, meaning that c() still gets evaluated.

Skipping the evaluation of c() seems particularly "magical" in my opinion and I'd prefer to always evaluate c().

Of the 37 examples from #17 (comment), two of them seemed like they might be affected by this:

@inputElement?.value = Trix.serializeToContentType(this, "text/html")

@activeHintMarker?.style?.zIndex = getNextZIndex()

[claudepache]

Unless you rely on side-effects – in which case you are responsible to learn exactly if and when evaluation occurs –, you won't see a difference. So, in order to avoid unnecessary work from the engine, I am for skipping the evaluation of the RHS.

[claudepache]

AFAICT, there are five cases where property assignment may occur, and where optional property assignment might be considered:

• simple assignment: a?.b = c
• combined assignment: a?.b += c, a?.b >>= c, etc.
• increment/decrement: a?.b++, --a?.b, etc.
• destructuring assignment: { x: a?.b } = c, [ a?.b ] = c, etc.
• for-in/of loop header: for (a?.b in c), for (a?.b of c)

[victornpb]

Another question is whether this code should evaluate c() if a is null:

a?.b = c()

if

a?.b.c().d = e;

is equivalent to:

if (a != null)
    a.b.c().d = e;

then

a?.b = c()

is quivalent to:

if(a != null) a.b = c();

[littledan]

This all gets a bit complicated. Do you have concrete use scenarios in mind that justify the complexity?

[claudepache]

@littledan Basically, concrete use cases are from the CoffeeScript samples linked in Comment 0. I’ve not delved deep into them, but here are two excerpts that seem reasonable at first sight:

@component?.element.component = null

and:

    modal = $('#create-account-modal').data('bs.modal')
    modal?.options?.keyboard = false

[littledan]

Is it this one, from #17 usage statistics?

Total soaked assignments (including compound assignments): 37

[claudepache]

Is it this one, from #17 usage statistics?

Yes.

[roippi]

My experience from dealing with assigning to deeply-nested-possibly-null structures has almost universally been that when there's a null I want to actually create the key and then successfully assign to it. I'm hard pressed to come up with a time when I'd want to skip the assignment entirely.

[samuelgoto]

Just wondering on the original question: if you leave assignment out, does it corner you? That is, if you completely ignore this feature and get the "read" in, does it prevent you (or make it harder) from ever doing the "write/assignment"?

If it doesn't, then it might be smart to de-couple and discuss these features in isolation (the "read" and the "write" separately) and turn this into a sequencing problem (i.e. in which order we bake things into the language, rather if we should or not)?

[claudepache]

@roippi

My experience from dealing with assigning to deeply-nested-possibly-null structures has almost universally been that when there's a null I want to actually create the key and then successfully assign to it. I'm hard pressed to come up with a time when I'd want to skip the assignment entirely.

Deeply-nested-possibly-null structures are not the unique use-case of optional chaining.

Here is a synthetic example. Suppose that I have an element of the DOM. If the element is found inside a <details> section, I want to open that section:

elem.closest('details')?.open = true