Syntax: Use ?& (or anything else that correct the inconsistency between a?.b and a?.[b]) #34
Comments
|
Sounds like a well thought through proposal. I believe the syntax is much more readable than the initial proposed ?. syntax(which just seemed wrong when being followed by ( or [ ). Is ?? totally off the table because of the nullary coalescing proposal? |
|
I think this is the right direction too (I agree that the consistency argument is a solid one). Can you walk us through the alternatives considered? In addition to I'm curious about |
There's a lot of discussion over in #5 about this, just search the page for
|
The main issue with |
|
@claudepache Would it be coupled with a |
|
What would be the use case? |
|
|
That's already |
|
Do we even need |
|
@saschanaz we would need all of |
|
@ljharb I think we can still differentiate them without the dot. |
|
@saschanaz that wouldn't be consistent; that way member access would be special and magic, and there'd be no explicit indication that it was using member access. |
|
PROS: "pedagogically better", "consistency" |
A major version bump to |
|
Yep, I think this is the best synthesis of all the proposals and issues raised thus far. Nicely done. If you're doubting the syntax, please 1) review all the linked material 2) get a feel by writing some fake code with it and 3) imagine syntax highlighting. After doing this, I'm pretty convinced this is a done deal. |
I’m not going to review in detail all suggestions I have seen (they are numerous); but I’ll try to give some criteria for comparing their merits: the ideal but impossible syntax is the one that meets all criteria. Here they are, approximately ordered by importance. Naturally, the real ordering will depend on your sensibility.
Now looking at few proposed syntaxes:
|
|
Let's not underestimate the ongoing human cost of a new and different syntax.
Is uniform access across three syntatical cases more important than precedent in other languages? (it's more about familiarity and being able to jump back and forth between languages). I think either Try visually scanning and typing the following two lines a few times to see how your eyes and fingers feel about the proposal;
(Typing ?. is incredibly easy on many layouts as the keys are adjacent. Throwing a far-away & between these two characters is painful) |
Compared to other language quirks like truthy/falsy and ASI, the burden of learning a slightly different operator seems negligible. I would rank uniform access as one of the most important qualities for this proposal, just below the parsing / compatibility requirements which rule out |
|
Why do you rank uniform access as more important than ease of use? (learning, typing) |
|
Uniform access directly correlates to ease of use. |
Uniform operators are inherent in ease of use. I don't have to think "is it
Null coalescing isn't an accepted proposal yet, so |
|
@damieng While I understand some of your sentiments, I think that the following argument is not valid:
It is strictly less worse to have two different syntaxes in two different languages, than two different syntaxes in the same language. In that regard, |
|
I think it's come to a point where there is no great solution, it would be good to get an off the cuff idea of what developers are willing to concede to though (perhaps via a targeted twitter poll), one thing with And I feel the ampersand in there actually compounds that glanceable confidence, as historically the ampersand is used with joining individual statements, so at a glance I'm getting mixed messages of:
And it takes that bit longer to realise, I would hope that with better syntax highlighting and time this proves to be a a non-issue. |
That's not true on it's own. It aids predictability but syntax can be both uniform and yet not easy to use if it's not short and accessible. I would argue Maybe it's just my hands hating the sequence (neither left nor right want's to drop & between two keys next to each other). I also find myself typing |
|
@claudepache 's bullet points are a great framework, thanks for putting that together. I don't think, however, I mentioned this live in the meeting, but just wanted to state here my intuition (I'll link to the notes too).
I don't think I generally rank criteria [3, 5] as high as @claudepache does. Like it was pointed out earlier, property access is by far the most common use case compared to ()-calls and []-access (matches my intuition and the data that was collected too). Given that there are no "perfect" solutions (e.g. ?., ?[] and ?()), I think it is a better trade-off to make the common use case super neat (a?.b) at the cost of not enabling (and cornering) the others (a?[b] and a?()). I propose we:
FWIW, this was proposed somewhere by somebody else too, I'll link it here. |
|
If we use |
|
that's correct and that's the trade-off that i think is worth taking to enable the more common form a?.b for property access. see earlier in my response:
|
|
How about something like this? For optional chaining: Null coalescing could go from |
I also proposed something similar: |
|
I'm honestly concerned by the push towards ??./??: for these operators and am with Hax here. As mentioned, there are ergonomics issues there. Those are very heavy operators, they require typing numerous characters, and they stand out a lot in code. To be frank and honest, I wouldn't want to write code that was riddled with heavy operators all over the place. Especially one that is so obvious. Is not part of the goal here to make coding more convenient, not less? If we boil it down, the most convenient approach here is ?./?()/?[]. This is terse and clean and blends nicely with the code. It's as simple as that. Anything other than that starts to become tedious and verbose, and with the dynamic nature of javascript, optional chaining will be heavily used. I understand there are syntactical and parsing concerns to be addressed, hence the reason for alternative syntax proposals. But let's not lose sight of the programming and human aspect here. Who in their right mind wants to be pounding out heavy optional chaining operators all day long in their code? In particular, consider the difficulty in typing these characters. One can simply hit period and be done with it. One MUST hit shift in order to type a question mark. Typing a backslash is even more difficult as one must contort their fingers to some degree in order to hit backslash off in the upper right side of the keyboard...of all the characters involved in the optional chaining operator, I find backslash to be one of the worst for this very reason. A colon also requires pressing shift, so if we did :? or something similar, one must have shift down for both characters, and the same goes for ?>. The more characters involved, the more complicated it becomes to actually type these operators out. Currently, ?. is a rather keyboard-friendly option. It may not be the most syntactically pretty, however it would be far more pleasant to type. |
|
Oh, I should note, ?& is maybe even worse than ?\ from a key location and typing standpoint. You either have to contort to use one hand to keep shift down while pressing both ? and &, or use two hands. I would say ?& and ?\ are far from ergonomic, and definitely not finger-friendly. Try typing these:
See how enjoyable it is. It's difficult, not a pleasant way to spend the day. :\ Ugly as heck, too! In one case, you've got a logical operator buried in your chain, in the other you have an escape operator. This is NOT confusing as all getout? The currently proposed operator, ?., is a natural extension of what we already do. We already separate object properties in a chain from each other with a period. Adding a question mark onto that to indicate the potential for undefined or null is a natural extension to what we already do, to our existing muscle memory, and it uses an easily accessed character. Please, let us not lose sight of the human aspect here. |
To be clear: Consider that we cannot use it, due to bad interaction with the conditional (ternary) operator. (A) True ambiguities when mixing conditional and optional chaining: a?[b]?[c]:d
// a ? ([b]?[c]) : d /* or */
// (a?[b]) ? [c] : d(B) Difficulty to parse efficiently. Moreover, we must prove that it is unambiguous: x*a?[b]+c // (x * a?[b]) + c
x*a?[b]+c:d // (x * a) ? ([b] + c) : dAlternatives have been explored and discussed since several months, and arguments have been made for all of them. At this point, we’ll most probably retain one of the two following options:
|
|
Are you really writing code that's riddled with maybe-nullish property lookup, such that |
|
Anyone sharing a pointer/post/comment about why |
|
@ljharb It really depends on the kind of application you are developing. Highly dynamic code can often involve more optional properties and null coalescence. |
|
@jrista can you share a non-contrived example with |
|
@claudepache Certainly. I understand the reasons why just a question mark alone is non-viable. I noted that in my previous post. I am just bringing it up to be clear that there is a human aspect here, and the farther we deviate from that ideal, just using a single question mark to denote optionality/two for null coalesce, takes us farther and farther from the most usable/typable proposal. |
|
@FranklinYu There's been a moderate amount of discussion of |
|
@FranklinYu: I've been in that thread. I believe there is overwhelming support for ?./?? with the total rank (accounting for votes against) being 158. There is underwhelming support for ??./??: with the total rank (accounting for votes against) being -20. shrug |
|
I want to repeat again:
|
|
Not that I think it might be the best idea, but has property |
|
@js-choi |
|
@hax It’s only fatal if you believe the majority of JS programmers in the future will come from, or will even have used, other languages. I suspect that over time, the majority of JS programmers will have only ever used JS, or JS will be their first language; if that is true, then JS will define what things mean, not other languages. |
|
@hax You are overestimating the confusion that would occur when having I use regularly, and even concomitantly, two languages that have different and incompatible use of the dot, namely PHP (string concatenation) and JavaScript (property access). It was far from fatal to my programming experience: the few times I have attempted to use the dot for string concatenation in JS, the outcome was buggy enough for me to realise my mistake quickly. That said I am open to hear horror stories that had resulted from such a situation... A point to note, and that will greatly help to mitigate the possible confusion, is that it is common style to surround the null coalescing operator with spaces, and yet a space-isolated |
|
My personal experiences:
So whether I agree or not agree "over time, the majority of JS programmers will have only ever used JS", I don't think it's acceptable to ignore the feelings of full stacks. And it will add pain to the programmers who mainly use JS but also other languages, and it will add a block to the programmers who use other language but try to use both JS and their first languages. |
While I see you are underestimating the confusion and possible accident.
This is a very good example. The key point is: the outcome must be buggy enough for you to realise the mistake quickly. But even PHP dot problem is not buggy enough. I happen to have some accident reports caused by it in my last company ! The buggy code can be simplified to Here You may argue, the coder should check whether the output is correct! I definitely agree with you, but people just make mistakes. Note, as a good tech team, we even have tools and process to protect us. But they all failed because:
After that, we finally added a hard-coded syntax check for the template to deal with the common issues. The interesting thing is, once a time, a newbie just wrote Even we didn't have such accident later, we can't stop wasting time on accidently write it and fix it when coding. It's too late to blame PHP using dot for a very different semantic (it come from perl, and perl6 just fix it by use
You are assume other languages all adopt space around style for And it can not solve |
|
How about we keep
This new sign remains read- and writable albeit not as easy as |
|
If it has an equals sign, a user will only expect one of two things: assignment for one equals, and comparison for more. |
|
I don't have a problem with The purpose of |
|
@lukescott function calls are perhaps debatable (although I have regular use for them in a |
|
@lukescott bracket access can never be dropped, no - not just for computed property access, but for Symbols, which can't be done with dot access. Without that symmetry between bracket and dot, the feature makes no sense. |
claudepache
added
the
alternative syntax
Clarify variable names and separation in examples
and others
After careful consideration (see in particular #5), I think that the best syntax satisfying the difficult constraints we face (strong BC, consistency) is the following:
Pros
?&token distinct from.is pedagogically better: One can picture the?&token checking whether the LHS is null/undefined and performing short-circuiting if applicable, then the subsequent.,[or(token performing regular property access or function invocation.Cons
?.in C#, Swift, CoffeeScript and Groovy, and&.in Ruby.)About the choice of ?&
?recalls that we are dealing with null/undefined, as this character is used in several languages for denoting an optional/nullable value or object.&recalls that the short-circuiting condition resemble the one of the&&operator (replacing “falsy” with “nullish”).?: “check for null”;&: “perform eventual short-circuiting”.The text was updated successfully, but these errors were encountered: