search

tc39 / proposal-optional-chaining

https://tc39.github.io/proposal-optional-chaining/
4.94k stars 75 forks source link

Clarify behavior of 'o?.m()' #16

Closed rbuckton closed 7 years ago

rbuckton commented 7 years ago

In C#, o?.m() returns null if o is null and does not throw. Given that in this proposal we have f?.(), which returns undefined if f is undefined, what is the expected behavior of o?.m() in this proposal?

  1. o?.m() returns undefined if o is undefined.
  2. o?.m() throws if o is undefined. To avoid the error, you must write o?.m?.().

If this proposal were to use the exact semantics of C#, then f?.() would not be legal, and you would instead need to write f?.call(). I'm not saying we should use the semantics of C#, just that developers from other languages with experience with this feature may intuitively believe that (1) is the correct behavior.

rbuckton commented 7 years ago

If I am following EvaluateCall correctly, it looks like (1) above is the correct interpretation according to 2.a.i. of the algorithm steps. It would be worth adding this example to https://github.com/tc39/proposal-optional-chaining#semantics.

jridgewell commented 7 years ago

See https://github.com/tc39/proposal-optional-chaining/issues/2.

rbuckton commented 7 years ago

Thanks. I still think it may be worth adding to the examples in README.md as its a common enough case.

claudepache commented 7 years ago

@rbuckton The README has already the following example: a?.b.c().d. But yes, there should be more explanations.

You can check the README of my own repo for more detailed explanations (https://github.com/claudepache/es-optional-chaining), although the “official” feature may have some differences.

claudepache commented 7 years ago

@rbuckton The updated README must answer your question. Please check and say if it is OK.