Discuss
  • Proposing a conditional assignment (or equals) operator

Proposing a conditional assignment (or equals) operator

# Doug Wade (9 years ago)

I see this has been discussed on this list a number of times before -- I found this thread esdiscuss.org/topic/new-assignment-operators-not-bit-wise-or, and

reviewed the linked discussions and previous strawmen (I hope that link is enough to establish context and why the operator is useful; I can provide more insight if it would be helpful). I understand the problem is fraught and thorny, but I believe the language would greatly benefit from it.

I spent some time reflecting on what I think would be expected of such an operator (most notably that it be as close to the other assignment operators +=, -= &c. and the || operator as I could manage, and that it match the ||= operator in Ruby www.rubyinside.com/what-rubys-double-pipe-or-equals-really-does-5488.html

fairly closely) and wrote up a quick reference implementation (-ish? see babylon (parser) doug-wade/babylon/tree/conditional-assignment and babel (compiler) doug-wade/babel/tree/babel-plugin-transform-conditional-assignment)

and an set of test cases doug-wade/conditional-assignment-tests to match what I

think expresses my thoughts on what I personally would expect from such an operator more eloquently than I think I could in words (please don't think me presumptuous; I thought it easier to write out my thoughts in code than English, not that the debate would be so simple that my implementation would be rubber stamped).

I have reviewed the process documentation tc39.github.io/process-document and the contributing guide tc39/ecma262/blob/master/CONTRIBUTING.md, and I

believe I am seeking a TC39 champion to make this a stage 0 strawman proposal, though I will admit that from my review of the archives esdiscuss.org there is likely to be a lot of discussion before

we reach that point. Please advise me as to what more I can do to get this included in the ES standard.

All the best, Doug Wade

# G. Kay Lee (9 years ago)

Not convinced. Failed to see any reason why this proposal could force its way through this time after repeatedly being raised from dead only to be put down time after time. I don't see any new, convincing rationales here. On the other hand I can give out two reasons on why we don't need this thing fair quickly:

// This is sooooo unambiguous everyone who knows programming can read this
const config = config || {};

// No true for this one as pointer out in previous discussions as well as
the Ruby article you mentioned
const config ||= {};

Honestly? Why are codes like this being written?

var config = {flag: true};
config = config || {};

...

function f (config) {
  const config = config || {};
}

I always write things like this:

var config = {flag: true} || {};

...

function f (config = {}) {
  ...
}

Can't remember any instance where I've written something like x = x || {} after the introduction of Default Parameters in ES6, so I don't see any chance for me writing something like x ||= {} even if this thing somehow makes its way in.

The thing is, it's far more common to encounter codes like x = y || {}, and then a new Default Operator would make sense due to the issue with falsy values. So I'd throw my support behind an authentic Default Operator proposal like x = y ?? {} ( strawman:default_operator). But definitely not ||=.

# Claude Pache (9 years ago)

Le 10 mai 2016 à 09:44, G. Kay Lee <balancetraveller+es-discuss at gmail.com> a écrit :

Can't remember any instance where I've written something like x = x || {} after the introduction of Default Parameters in ES6, so I don't see any chance for me writing something like x ||= {} even if this thing somehow makes its way in.

Some people do have use cases despite default arguments, see e.g. esdiscuss.org/topic/is-much-needed#content-4, esdiscuss.org/topic/is-much-needed#content-4

The thing is, it's far more common to encounter codes like x = y || {}, and then a new Default Operator would make sense due to the issue with falsy values. So I'd throw my support behind an authentic Default Operator proposal like x = y ?? {} (strawman:default_operator, strawman:default_operator). But definitely not ||=.

Agree. I wonder why people keep to reclaim a ||= operator (with semantics inspired from binary ||), when their use cases generally show that ??= is more appropriate (with approximate semantics of: if (a === undefined) a = b;).

# Bruno Jouhier (9 years ago)

A big +1.

A quick grep on our code base shows 3000+ occurrences of the x = x || y idiom in 700+ files. This proposal would make this code more compact and more efficient, as it avoids redundant assignments.

The x = x && y idiom is a lot less common: 150 occurrences only, and is usually associated with questionable reuse of a polymorphic variable to walk a chain. But it would seem logical to extend the proposal to &&=.

Bruno

# Bruno Jouhier (9 years ago)

??= is cleaner and avoids problems when the default is falsy but not undefined. But then we also need ??.

# Isiah Meadows (9 years ago)

Thought I'd mention this has been discussed before:

esdiscuss.org/topic/optional-chaining-aka-existential-operator-null-propagation

Currently, here's what I've seen emerge out of these discussions as the most likely, each of them chainable:

  1. x ?? y for x != null ? x : y
  2. x??y or x?.y for x != null ? x.y : undefined

In #2, the operator works similarly for computed access, function calls, etc., like in f?.(x) equivalent to f != null ? f(x) : undefined

# Ari Porad (7 years ago)

Given that optional chaining is now stage–1, would there be interest in reviving this proposal? (This idea originated from my comment here.)

Apologies if this isn’t the proper way to suggest this idea, it’s my first time posting on es-discuss!

# Isiah Meadows (7 years ago)

I'd like to see it myself, actually. Currently, the closest we have is this (which only works for undefineds):

[foo = "default"] = [bar]
# Claude Pache (7 years ago)

This feature is more related to null coalescing (evaluate the RHS when the LHS is null) than to optional chaining (evaluate the RHS when the LHS is not null).

See gisenberg/proposal-nullary-coalescing#1

# kai zhu (7 years ago)

this proposal is not as useful as you would think. when integrating with api's and modules not written by yourself, you will always be self-doubting whether the "other" guy who wrote their code used null/undefined/false/0/<empty string> values, causing you to avoid

using this feature in general.

the <empty string> is commonly treated as a defacto null when reading

dom-element attributes or when fetching web

# Alexander Jones (7 years ago)

For what it's worth, doubling down on a design that exposes such poor choices wouldn't necessarily be a bad thing ;)