Poll: Operator Syntax

[gisenberg]

Hey folks,

I wanted to pull out and highlight the options that have been raised in the syntax thread, as not all options were presented and they are now somewhat buried. Please use the response buttons to vote and keep comments related to syntax in #34

[gisenberg]

?.., ?.() and ?.[], with null coalescing taking the ?? token

[gisenberg]

!., !() and ![] with null coalescing taking the ?? token

[gisenberg]

?&., ?&() and ?&[] with null coalescing taking the ?? token

[gisenberg]

?>., ?>() and ?>[] with null coalescing taking the ?? token

[gisenberg]

?., ?.() and ?.[] with null coalescing taking the ?? token

[gisenberg]

??., ??() and ??[] with null coalescing taking the ??: token

[TheNavigateur]

\., \() and \[] with null coalescing taking \\

[Tiedye]

:?., :?() and :?[] with null coalescing taking the ?? token

[Kerrick]

~., ~() and ~[] with null coalescing taking the ?? token

[jrista]

Why is there not an option for:

?., ?(), ?[]?

This seems like the most natural approach. Throwing a . between ? and () or [] is very syntactically strange.

[gisenberg]

@jrista Please see #5 (comment) and claudepache/es-optional-chaining#3 for additional context. The obvious solution is not an option.

EDIT: Also, see #52

[jrista]

Thanks.

[kacgrzes]

I believe we have a clear winner here. Following Optional chaining in Swift and Safe Calls in Kotlin, ?. seems to be the way.

[ljharb]

For better or worse, specs aren’t decided by a popularity contest. ?. is inconsistent and is almost definitely not going to be able to achieve consensus (it’ll get its fair shot, but I’m trying to set expectations)

[scottrippey]

Is it syntactically possible to allow this syntax?
a && .b, a && .[i], a && .()
This could be extended to ternaries too, like a ? .b : 0

[claudepache]

Is it syntactically possible to allow this syntax?
a && .b, a && .[i], a && .()

Probably, but Optional chaining has different semantics than current && with respect to short-circuiting: Current && operator checks for falsy, while optional chaining checks for nullish.

(I’ve proposed to use ?& instead, but it didn’t have much success.)

[Mouvedia]

?., having to surround the expression with parentheses for ?[] and ?()
(with null coalescing taking the ?? token)

[FranklinYu]

.?., .?() and .?[] with null coalescing taking the ?? token

_{mentioned in #34 (comment) by @hax}

[ScottRudiger]

@ljharb

For better or worse, specs aren’t decided by a popularity contest. ?. is inconsistent and is almost definitely not going to be able to achieve consensus (it’ll get its fair shot, but I’m trying to set expectations)

I think it's been established that there's likely no option able to achieve complete consensus
(i.e., unanimous).
But, there's an option capable of satisfying most.

"[W]e are unlikely to satisfy everyone."
- gisenberg

"I realize that it's impossible to satisfy everyone [...]."
- hrishikeshs

"I had to admit that all alternatives may have pros and cons, which can not satisfy everyone [...]."
- hax

"It seems pretty clear that there is no option which will get absolute consensus as the top choice among everyone participating in this thread."
- littledan

"No operator proposal satisfies everyone (yet), it seems. That's because every proposal has tangible drawbacks vs one or more of the others (whether you like to admit it or not)."
- TheNavigateur

"[Yet,] it's also possible that this is going to affect millions of JavaScript developers."
- damieng

"[...] I believe [the option] most likely to satisfy the majority is ??. with nullish coalescing taking the ??: token."
- gisenberg

"I think many might agree that if it wasn't for the ?. ?.[ ?.( inconsistency factor, ?. is one of the more optimal choices."
- me

"[M]any programmers don't find the inconsistency of a?.x a?.[y] a?.() in the first place."
- hax

"[...] It sure looks like I am not the only one. #51 shows that the current implementation (?.) is still the most popular one, while the new proposal (??.) appears to be rather unpopular."
- lehni

The question is: the most of who?

Is the size of this group

1?
3-4?	contributors/members involved in this proposal
30-50?	TC39 members attending the next meeting(s)
200-300?	real JavaScript users participating in this poll
2-6 million plus?	highly conservative post-googling estimate of JavaScript developers worldwide
21 million plus?	total software developers worldwide who might touch JS (growing ~1m/yr--and this may be a serious underestimate)

I'm not intimately familiar with the inner-workings of TC39, but I'd venture to guess the answer is realistically 30-50 with strong emphasis on input from 1-4.

If that's the case, I would hope that whomever is presenting this proposal next includes the results of this poll as significant evidence of the direction to take.

In any case, I think it's important for this discussion to be clear about who exactly it is you're striving for consensus with. Knowing the answer to that, our expectations may be tempered.

[claudepache]

The two most popular choices are, at the time of writing:

1. ~90%: optional chaining: ?. / ?.[ / ?.( — null coalescing ??
2. ~38%: optional chaining: ??. / ??[ / ??( — null coalescing ??:

The third one (?..) gained ~20% votes.

They are roughly the same two as in a previous poll, although in different order. (I say ”roughly”, because the choices in the previous poll had some differences relatively to this one.)

It seems clear at this point that we’ll pick one of those two options. Which one, will not depend solely on popularity, since we should strive to have what is the best for developers, not what pleases them the most.

[TheNavigateur]

Isn't what's best for developers the same as what pleases them the most, at least in the long term?

Otherwise how could you possibly define "best"?

Of course I accept that what pleases developers now may not please developers in the future, which is what I think your point is

[claudepache]

Isn't what's best for developers the same as what pleases them the most, at least in the long term?

Otherwise how could you possibly define "best"?

Of course I accept that what pleases developers now may not please developers in the future, which is what I think your point is

As a trivial example of dissonance between ”pleasing” and “best”, a developer may want x.y to ”just work” even when x is undefined, but not realising that it will cause them much headache when debugging any complex code.

For the particular case of Optional chaining, I am currently not sure what is the best. Different syntaxes, including ??., have been discussed since several months, and ??. has attained a rough consensus amongst those most involved in the proposal. Very recently (at most two weeks ago, after PR #48 has been opened), strong resistance has become manifest, and the debate in #34 became very heated. Some good points have been made, but it has generated more heat than light. We (those involved in the proposal design) need to keep a cool head and consider if the arguments recently made are enough to change the rough consensus.

[TheNavigateur]

"Headache" is not pleasing, so we are talking about the same thing, just from a longer term / wider perspective.

Otherwise there is no way of measuring "best".

The solution is probably to take a poll among those who have engaged fully in consideration & conversation about the various alternatives, which is what I think your point is.

[felix9]

a.?b, a(?b), a[?b], a??b

[jhpratt]

Just a general note, I think it's important to point out that the nullish coalescing operator implicitly depends on the result of this decision. For those favoring syntax that would result in using ??: for nullish coalescing, remember that there will be an assignment operator to match. Is ??:= really what you want?

Between the options of ??:= and ???=, I'd personally prefer the latter by far.

Just some food for thought.

[TheNavigateur]

Might be just me but I'm totally comfortable with ??:=

[davegregg]

If that's what we end up with, we can call it the Combover Zoidberg operator.

[dwelle]

Slight variation on @shannon proposal, leaving out the . in ??.:

??, ??[], ??(), null coalescing ???

obj??prop
obj??deep??prop
obj??[prop]
obj??call??()

[cxw42]

@dwelle I think it's fine, but see #51 (comment)

I have a bold/foolish suggestion :) . Would the committee please pick a syntax and move on? Those of us who don't like the committee's choice can write Babel plugins to give us our preferred operator :D .

(Yes, I know forking a language is a Bad Thing. I also know that transpiling is here to stay, so perhaps we really could use it to relax some of the constraints.)

[ljharb]

@cxw42 if a syntax is picked, babel will drop support for the other ones - you won’t be able to use them moving forward.

[Zarel]

@ljharb Babel has a plugin system – anyone can write their own plugins for any syntax at all.

In addition, Babel is open-source, so the change is a pretty direct process of forking the official plugin and changing the syntax it supports.

This is what @cxw42 means by "write Babel plugins".

[ljharb]

@Zarel no, anyone can write plugins for the syntax that Babylon supports. Babel intentionally does not allow wild syntax experimentation. Certainly you could fork, but you can do that now whether a decision is made or not.

[jridgewell]

I’m a core maintainer on Babel: @ljharb is correct here. The parser is not designed for custom plugins, only the transformer.

[cxw42]

@jridgewell @ljharb Thanks - I learned something today!

I'm signing off the thread - good luck to all!

[hax]

@jridgewell I agree use Babel for some arbitrary syntax variant is not a good idea, but just want to point out that babel parser also have a plugin architecture, just never expose it outside uptonow. I'm not sure whether expose such functionality is ok. At least anyone can fork babel if they really want 😅

[hpoul]

Is it syntactically possible to allow this syntax?
a && .b, a && .[i], a && .()

why is everyone hating that suggestion? It wouldn't even need new syntax, like how about extending the && operator to set a special variable on the right side with the result of the previous expression.. for example with _ it could be a && _.b && _.c instead of a.b.c this would even allow fancy stuff like a && myFunc(_) && _['attr'] -- i guess it has not much to do with optional chaining, but it might make it unnecessary to have anything but optional access to static property accesses ?. and everything else (e.g. method calls a && _.method()) easy to use with the && operator. (ignoring the fact that && checks for falsy and not null).

(the whole point of optional chaining is to reduce clutter, otherwise i could just rewrite the whole expression on the right side of && .. but imho && _ is short enough.. just like a 3 character difference to ?. I guess it's impossible because people are using _ as variable names, but anyway.)

[hax]

@hpoul If use a notation contains &&, the semantic should also use truth test , but I think most people want nullish test semantic.

[jeniasaigak]

I really like the idea to use question mark, but I don't like this examples: ?.() and ?.[]. Looks like this dot is unneeded.

Why is there not an option for:

?., ?(), ?[]?

This seems like the most natural approach. Throwing a . between ? and () or [] is very syntactically > strange.
@jrista

I do like this approach, but including the fact that there is a reason why it cannot be used (#51 (comment)), maybe there is a sense to use the same but with some other symbol? At this article which was mentioned above there are a lot of implementations for it from other languages and my proposition is to use some other symbol (from other languages implementations) instead of question mark. In this case this operator will be better identified for people who came from other languages (or work with other languages in parallel) and there will be no parse issue.

So from other languages we can see that there are 2 suitable symbols for it: & and ?. So maybe it will be better to just replace ? with &?

That is how it will look: &., &() and &[]

[claudepache]

@zmefz The subject has already been extensively discussed; many alternatives have been proposed, and none of them gained more favour than the currently proposed syntax. The issue is known since several years.

For your particular suggestion, &() and &[] is not possible for exactly the same reason as ?() and
?[]: conflict with some already existing operator.

[TheNavigateur]

I think it's decision time. Cater to the developers of the future, not of today (and their "other language" biases), as it will be a decision forever, and JavaScript will be THE language (at least for the foreseeable future). Given that, I think the decision should be clear and obvious (at if not, at least make a decision). You have my regards

[Mouvedia]

I think the decision should be clear and obvious…

I agree, we should resolve ourselves to the consensus which is to move on with just ?. leaving dynamic property access and function call for a later time. It's better than nothing.

[TheNavigateur]

I don't know if this is your intention, but this would force ?.( and ?.[ for those "at a later time", which would introduce a syntactic inconsistency which is bad for future developers. Today's consensus is biased by other languages which safely provide ?( and ?[. It is a consensus today because .property is the most common case which makes it appealing to introduce ?. to mirror those languages. Future developers won't be biased by other languages - often they will see the feature in JavaScript first, and that logical inconsistency would definitely not be justifiable then. Future developers should be catered for, not today's, because the decision is forever.

[jeniasaigak]

For your particular suggestion, &() and &[] is not possible for exactly the same reason as ?() and
?[]: conflict with some already existing operator.
@claudepache

Yes, you're totally right, I've fully forget about this operator.

[TheNavigateur]

@ScottRudiger would you be comfortable to reveal the reasons for your thumbs down? I would benefit from knowing why I'm wrong, if so. Otherwise have a great day anyway

[Zarel]

@TheNavigateur You were thumbed-down because Claude's post right above yours already answers your post:

The subject has already been extensively discussed; many alternatives have been proposed, and none of them gained more favour than the currently proposed syntax. The issue is known since several years.

The thumbs-down is because if you won't even read the post right above yours, it seems unproductive to argue with you.

You seem to be confused about the state of the proposal. You say things like "it's decision time", but decision time was months ago. We already decided, after five years of arguing.

You haven't said anything new, only things that we've already thought about. We're aware that ?.[ and ?.( are inconsistent. We've considered dozens of alternatives, including some really creative ones like #77. You come in and tell us they're inconsistent, as if that wasn't what we've already spent the last five years thinking about. All alternatives have their flaws. This was the best compromise.

[ScottRudiger]

@TheNavigateur Sure, the thought behind my 👎 was simply to reiterate my (and many others'--just a sample: 1 2 3 4 5 6) take on it: that the "inconsistency" between ?. ?.[ and ?.( is not a big deal. Like mentioned here, here, here and elsewhere, it's time to move on with the proposal as is.

[claudepache]

Maybe that this gh issue, and many others in this repository, could have already been closed as resolved. I was waiting the outcome of the March TC39 meeting, where they may decide to advance this proposal to stage 2, at which point I plan to do heavy housekeeping.

[jrista]

Here is to hoping things go well in March! Really looking forward to this operator. :)