Using the name "safe-navigation" operator instead of "optional-chaining"

[Daniel-Khodabakhsh]

As far as I can tell, the inventor of the operator was Groovy, using the name "Safe-navigation operator". This name is more intuitive and concise to the purpose and result of the operation, as the user is attempting to safely obtain a member along an object path.

Conditional Optional-chaining more closely resembles one of the hacks people used in Javascript to obtain the same effect: ((object || {}).property1 || {}).property2 || null where chaining could either refer to the chain of conditions which must be met, or the chain in the sense of the object path.

Would it not be better to pay homage and respect the first creator of the operator?

[ljharb]

Objects are not paths to navigate, and there’s nothing “safe” about it - you can still get exceptions if getters throw. I don’t think it’s an appropriate name.

[claudepache]

Conditional-chaining more closely resembles one of the hacks people used in Javascript to obtain the same effect

”Optional”, not ”conditional” (and no, it isn’t meant to resemble to any sort of hack).

---

Among the various names of the feature in other languages, I picked the one that describes better the feature for me. Although we can take time to bikeshed the name, I don’t think it is worth, unless one name is markedly better than the other.

[Daniel-Khodabakhsh]

Objects are not paths to navigate, and there’s nothing “safe” about it - you can still get exceptions if getters throw. I don’t think it’s an appropriate name.

I see your point about it not being safe, but it definitely is safe-er. In fact, the main purpose of the operator is to avoid exceptions being thrown when trying to access a member when the object is null. In this context I think "safe" or "safety" are appropriate words. If this is wrong, what would you say the main purpose of the operator is?

Also, objects are typically arranged in hierarchies which can be seen as paths, just like web addresses. It's a valid analogy and I think that's why the creators of Groovy chose this name.

Why is it currently called Optional-chaining? Is it 'optional' because the result may or may not produce a null? Conditional seems to be more appropriate in this context (which is probably why I made my mistake in the original posting). Optional implies agency, as in someone having an option to alter the result. Additionally, I would argue that 'chaining' implies bidirectional interaction. When writing code, you typically build a "path" or "navigate" to the desired resource. I don't feel 'chaining' describes this process very well.

Although we can take time to bikeshed the name, I don’t think it is worth, unless one name is markedly better than the other.

Shouldn't the default position be that of using the existing name of the operator? You wouldn't rename the '+' operator anything other than the 'addition' operator.

[rkirsling]

Why is it currently called Optional-chaining?

I believe this is primarily a Swift-ism, but they call Option/Maybe types "Optionals" (Optional<T>, or more normally T?), hence "Optional" is a noun in their context. Given that "an Optional" isn't a JS concept though, I guess you're right that this would be a newly-invented phrase in which "optional" is an adjective.

[claudepache]

In fact, the main purpose of the operator is to avoid exceptions being thrown when trying to access a member when the object is null. In this context I think "safe" or "safety" are appropriate words. If this is wrong, what would you say the main purpose of the operator is?

Optional chaining is not about safety, but about brevity. IOW, I don’t expect a?.b to be used as a replacement for a.b (possibly embedded in a try/catch block), but as a replacement for if (a) { a.b } (or any variant thereof).

[claudepache]

I believe this is primarily a Swift-ism

Yes, although I’ve (re)interpreted ”optional” as an adjective.

If you want to avoid ”optional”, alternatives are ”nullish-conditional” or ”nullish-guarded”. But not ”safe”.

[Daniel-Khodabakhsh]

Thanks for that information @rkirsling. I don't have a background in Swift and never came across the 'Optional' terminology which threw me off.

If you want to avoid ”optional”, alternatives are ”nullish-conditional” or ”nullish-guarded”. But not ”safe”.

I think 'nullish-guarded' is really good. What about 'nullish-guarded-accessor'? This would be much more descriptive than even 'safe-navigation'.

[rkirsling]

I fear that "X-guarded" more readily sounds like "guarded by X" than "guarded against X" (cf. "semaphore-guarded critical section"), but I agree that guarded accessor / guarded access operator sounds quite nice.

I suppose the only concern there is whether ?.() feels left out, but I think "guarded access" is far more inclusive of calls than, say, Kotlin's "safe call" is of accesses.

---

Edit: FWIW, Dart calls this "conditional member access", so even if we don't like "conditional", that's a point for "access".

[claudepache]

FWIW, Dart calls this "conditional member access", so even if we don't like "conditional", that's a point for "access".

I find ”access” inaccurate, given that the short-circuited part may contain method calls, as in: a?.b.c(x).d. Is ”chaining” really wrong?

[rkirsling]

a?.b.c(x).d

This doesn't seem to be a counterexample—there's only one ?., which is not touching a method call, and even c(x)?.d would still be a guarded dot-access on the return value.

If the concern were about c?.(x) though, I could surely understand wanting to be explicit and say, e.g., "guarded access and call operators".

Is ”chaining” really wrong?

All sorts of things can be chained, so I absolutely don't think it's wrong, just a little vague. But then I suppose people will probably call it "question-dot" regardless of the official name. :smile:

[Daniel-Khodabakhsh]

I think 'chaining' is good at describing the overall syntax when the operator is used multiple times, like Method chaining. However, method chaining itself doesn't name it's operator(s) with the word 'chaining'. It's a combination of method calls and member access / structure reference operators.

That being said, I'd be ok with the word 'chaining' with the above considered.

Here are the names which I think are good so far:

• guarded chaining operator
• guarded access and call operator
• guarded access operator
• guarded accessor
• safe chaining operator
• safe access and call operator
• safe access operator
• safe accessor
• safe navigation operator (original Groovy name)

[Mouvedia]

Personally Id pick speculative access operator. I agree with @claudepache: at this point it's pure bikeshedding. What really matters is #5 and the confidence that we won't introduce something as awful as ?.[]. Once that's settled, you can rename it however you want.

[vonwao]

I vote for null-safe-accessor. Who cares if it's not 100% accurate. It's the actual use case. It's something 100% of people can understand.

Remember JS is a language for regular people, not uber-technical programmers who get hung up on techie words.

[jorroll]

@vonwao As someone who has been programming with javascript for only ~2 years, I find null-safe-accessor to be confusing. Intuitively, I would expect it to only work on null. Without commenting on the merits of that name verses any other, nullish is more descriptive than null.

[claudepache]

I vote for null-safe-accessor. Who cares if it's not 100% accurate. It's the actual use case. It's something 100% of people can understand.

“Safe” is something I didn’t understood until I saw an explanation, and when I saw it, I was hoping it wasn’t the actual use case... I don’t know whether it’s because I have a different philosophy of programming than some people (that is, I try to avoid errors rather than recover from them), or because it was an intentional abuse of language I couldn’t get used of.

The expected use case of optional chaining is to take different actions when a value is null (or undefined) and when it is not. This has nothing to do with safety, this is control flow like an if statement.

For me, it is not “protect against the TypeError that would occur when trying to access a property of null” as I have heard, because I wouldn’t ever try to access a property of null: If I expect that the value is sometimes null, I test that condition before attempting to access the property. If I don’t expect the value to be null but it occurs nevertheless, I try to correct the root of that bug rather than its symptom.

Remember JS is a language for regular people, not uber-technical programmers who get hung up on techie words.

Indeed. Über-technical programmers can understand the feature whatever it is named. But regular people are helped if the feature has not a misleading name: it’s not about making their code safer.

[rkirsling]

FWIW, "nullish-aware" is another option which has precedent but hasn't been raised here. (See: https://github.com/dart-lang/language/issues/404, https://www.python.org/dev/peps/pep-0505/)

[hax]

An incomplete name list:

• Groovy: safe navigation operator / safe dereferencing
• Kotlin: safe calls / safe navigation
• Perl 6: safe call operator
• Ruby: safe navigation operator
• C#: null-conditional operators (null-conditional member access / null-conditional element access)
• Dart: conditional member access / conditional method invocation / conditional property extraction / null-aware conditional form
• Python: None-aware attribute access / None-aware indexing
• CoffeeScript: existential operator
• Swift: optional chaining

[claudepache]

Name change didn’t happen before stage 4.