Re: Proposing a conditional assignment (or equals) operator

[Alexander Jones]

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

On Wed, 16 Aug 2017 at 02:56, kai zhu  wrote:

> 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/ values, causing you to avoid
> using this feature in general.
>
> the  is commonly treated as a defacto null when reading
> dom-element attributes or when fetching web-data
>
>
> On 8/15/17, Claude Pache  wrote:
> > This feature is more related to null coalescing (evaluate the RHS when
> the
> > LHS is null) than to optional chaining (evaluate the LHS when the LHS is
> > *not* null).
> >
> > See https://github.com/gisenberg/proposal-nullary-coalescing/issues/1
> > 
> >
> > —Claude
> >
> >> Le 15 août 2017 à 03:11, Ari Porad  a écrit :
> >>
> >> Hi All,
> >>
> >> Given that optional chaining is now stage–1, would there be interest in
> >> reviving this proposal? (This idea originated from my comment here
> >> <
> https://github.com/tc39/proposal-optional-chaining/issues/18#issuecomment-322329156
> >.)
> >>
> >> Apologies if this isn’t the proper way to suggest this idea, it’s my
> first
> >> time posting on es-discuss!
> >>
> >> ___
> >> es-discuss mailing list
> >> es-discuss@mozilla.org 
> >> https://mail.mozilla.org/listinfo/es-discuss
> >> 
> >
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposing a conditional assignment (or equals) operator

[kai zhu]

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/ values, causing you to avoid
using this feature in general.

the  is commonly treated as a defacto null when reading
dom-element attributes or when fetching web-data


On 8/15/17, Claude Pache  wrote:
> This feature is more related to null coalescing (evaluate the RHS when the
> LHS is null) than to optional chaining (evaluate the LHS when the LHS is
> *not* null).
>
> See https://github.com/gisenberg/proposal-nullary-coalescing/issues/1
> 
>
> —Claude
>
>> Le 15 août 2017 à 03:11, Ari Porad  a écrit :
>>
>> Hi All,
>>
>> 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!
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org 
>> https://mail.mozilla.org/listinfo/es-discuss
>> 
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposing a conditional assignment (or equals) operator

[Claude Pache]

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

See https://github.com/gisenberg/proposal-nullary-coalescing/issues/1 


—Claude

> Le 15 août 2017 à 03:11, Ari Porad  a écrit :
> 
> Hi All,
> 
> 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!
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org 
> https://mail.mozilla.org/listinfo/es-discuss 
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposing a conditional assignment (or equals) operator

[Isiah Meadows]

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

```js
[foo = "default"] = [bar]
```

On Mon, Aug 14, 2017, 21:11 Ari Porad  wrote:

> Hi All,
>
> 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!*
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposing a conditional assignment (or equals) operator

[Ari Porad]

Hi All,

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!___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposing a conditional assignment (or equals) operator

[Isiah Meadows]

Thought I'd mention this has been discussed before:

- https://esdiscuss.org/topic/existential-operator-null-propagation-operator
- https://esdiscuss.org/topic/the-existential-operator
-
https://esdiscuss.org/topic/optional-chaining-aka-existential-operator-null-propagation
- https://esdiscuss.org/topic/proposal-for-a-null-coalescing-operator
- https://esdiscuss.org/topic/operator-was-es6-doesn-t-need-opt-in

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`

On Tue, May 10, 2016, 08:50 Bruno Jouhier  wrote:

> `??=` is cleaner and avoids problems when the default is falsy but not
> undefined. But then we also need `??`.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposing a conditional assignment (or equals) operator

[Bruno Jouhier]

`??=` is cleaner and avoids problems when the default is falsy but not
undefined. But then we also need `??`.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposing a conditional assignment (or equals) operator

[Bruno Jouhier]

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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposing a conditional assignment (or equals) operator

[Claude Pache]

> Le 10 mai 2016 à 09:44, G. Kay Lee  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. 
https://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 ?? {}` 
> (http://wiki.ecmascript.org/doku.php?id=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;`).

—Claude___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposing a conditional assignment (or equals) operator

[G. Kay Lee]

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:

1.
```
// This is so 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 ||= {};
```

2.
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 ?? {}` (
http://wiki.ecmascript.org/doku.php?id=strawman:default_operator). But
definitely not `||=`.


On Tue, May 10, 2016 at 12:10 PM, Doug Wade 
wrote:

> I see this has been discussed on this list a number of times before -- I
> found this thread
> ,
> 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 +=, -=  and the || operator as I could manage, and that it
> match the ||= operator in Ruby
> 
>  fairly
> closely) and wrote up a quick reference implementation (-ish? see babylon
> (parser)
>  and babel
> (compiler)
> )
> and an set of test cases
>  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
>  and the contributing guide
> , 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
>  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
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss