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 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 ||= {};
```
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 <douglas.b.w...@gmail.com>
wrote:
> I see this has been discussed on this list a number of times before -- I
> found this thread
> <https://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
> <http://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)
> <https://github.com/doug-wade/babylon/tree/conditional-assignment> and babel
> (compiler)
> <https://github.com/doug-wade/babel/tree/babel-plugin-transform-conditional-assignment>)
> and an set of test cases
> <https://github.com/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
> <https://tc39.github.io/process-document/> and the contributing guide
> <https://github.com/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
> <https://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
>
> _______________________________________________
> 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
