tc39 / proposal-optional-chaining

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

Alternative syntax #50

Closed PFight closed 6 years ago

PFight commented 6 years ago

Syntax of function call (foo?.()) and accessing array element (array?.[i]) is quite uggly. The reason as known - problems with parsing, because of ternary operator ? :, so we can't use foo?() and array?[i].

I suggest change syntax a bit, and make different operator ?? for function calls and array access.

  1. Member access: user?.address?.street - no changes
  2. Function call: myForm.checkValidity??() instead of myForm.checkValidity?.()
  3. Array access: myArray??[i] instead of myArray?.[i]

It's looks nice and has no problem with parsing. What do you think?

ljharb commented 6 years ago

Having all three of those not be consistent is a problem; they’re conceptually the same kind of operator.

PFight commented 6 years ago

Another variant, change point 1 too:

user??.address??.street

PFight commented 6 years ago

@ljharb all these cases are not the same. What is operator ?. should mean? In first point it is accessing member (user?.address), but in second and third it is not accessing member. There we getting some value, and applying to it function call or array access.

myForm.checkValidity?.() is the (myForm.checkValidity?.) ()

So, if we are going to keep consistent, then we should write:

user?..address because it is (user?.).address

So, there is no consistence right now.

ljharb commented 6 years ago

The current proposal is ?. ?[, and ?(, with nullish coalescing as ??.

After #48, the proposal will be ??., ??[, and ??(, and nullish coalescing will be ??:.

In both cases, all three optional chaining operators are <token>., <token>[, and <token>(. This is an important and necessary characteristic.

PFight commented 6 years ago

Hm, REAMDE is outdated...

claudepache commented 6 years ago

The current proposal is ?. ?[, and ?(, with nullish coalescing as ??.

Correction: it is currently ?., ?.[, and ?.(


Closing this as a duplicate of #5 and/or #34. As @ljharb mentioned, this is expected to be resolved by PR #48.