Add Note about short-circuiting behavior

[bcoe]

As this proposal matures, the reference to the prior proposal in the spec text feels like it's probably no longer needed:

An early version of this proposal used a Nil reference to express short-circuiting. This one is based on syntax only.

Perhaps instead add a Note: on OptionalChain about how this part of the grammar facilitates Long short-circuiting?

[rkirsling]

If I understand correctly, the first section of a proposal's spec text is specifically intended as a "foreword" for reviewers and isn't something that ends up in the resulting ECMA-262 PR. So I think that reference is potentially useful for following the trajectory that this proposal has taken in its long road to Stage 2.

It could well be worthwhile to add another explanatory sentence to the section 3.8 note though. :+1:

[claudepache]

If I understand correctly, the first section of a proposal's spec text is specifically intended as a "foreword" for reviewers and isn't something that ends up in the resulting ECMA-262 PR.

Exactly. I’ll try to make this point clearer when I’ll take time to rewrite the foreword of the spec text (I expect: in about two weeks).

It could well be worthwhile to add another explanatory sentence to the section 3.8 note though.

I don’t think so. The sentence in question is more about the history of this proposal (and it could even be improved in order to actually help the reviewers). But once the “right” way is specced, it needs neither to justify itself, nor to hint at the alternative “wrong” ways that were tried before.

[bcoe]

@claudepache works for me. If I understand your reasoning, we went down a path in the previous version of the spec which required annoying exceptions to handle short-circuiting; with the latest version, we have appropriate behavior by default, and there's no need to draw attention to this?