Re: operator overloading proposal

> I would prefer syntax + internal slots, since you'll know at creation time whether the object has overloaded > operators. It's much simpler for the engine to figure out, and it's more performant because you only need to > check one thing instead of worrying about inheritance, own properties,

Re: operator overloading proposal

You're correct in that the operator doesn't do any type checking (it dispatches from its first argument, but that's just traditional OO). On Tue, May 10, 2016, 20:28 kdex wrote: > @Isiah: Comparing your syntax proposal to `Function.defineOperator`, it > appears to me that >

Re: operator overloading proposal

@Isiah: Comparing your syntax proposal to `Function.defineOperator`, it appears to me that overloading an operator multiple times (e. g. unary/binary plus operator) might become painful, assuming that the semantics follow the same variadic approach that regular functions do. That is, of

Re: Re: Existential Operator / Null Propagation Operator

Why isn't it possible to use the obj.property?.sub syntax in combination with lookahead as suggested by Brendan Eich 4 years ago? http://wiki.ecmascript.org/doku.php?id=strawman:existential_operator ___ es-discuss mailing list es-discuss@mozilla.org

Re: operator overloading proposal

Here's my thought, if we go with syntax. ```js class Point { // constructor, etc. operator +(other) { assert(other instanceof Point) return new Point( this.x + other.x, this.y + other.y) } operator +=(other) { assert(other

Re: Proposing a conditional assignment (or equals) operator

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 -

Re: operator overloading proposal

A note on this from somebody who's entire existence seems dedicated to stopping as much stuff as possible from getting GC'd, the example below: >const u = new Point(5, 10); >const v = new Point(1, -2); > >const w = u + v; // desugars to u[Symbol.add](v) >console.log(w); // { x: 6, y: 8 };

Re: operator overloading proposal

I would prefer syntax + internal slots, since you'll know at creation time whether the object has overloaded operators. It's much simpler for the engine to figure out, and it's more performant because you only need to check one thing instead of worrying about inheritance, own properties, etc.

Re: Proposing a conditional assignment (or equals) operator

`??=` 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: Is `undefined` garabage collectable?

Arrays are probably your best bet (but don't ever `delete` elements, or change the size of your array!). I don't understand what you mean by "placeholder". But FWIW, array keys (i.e., small integers) are usually unboxed, i.e., not heap-allocated. A general advise, though: don't be over-concerned

Re: Proposing a conditional assignment (or equals) operator

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

Re: Proposing a conditional assignment (or equals) operator

> 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 ||=

Re: operator overloading proposal

Yes, I think exposing operators through well-known symbols is an interesting idea worthy of more exploration because it's precisely the purpose of well-known symbols to expose and allow manipulation to previously inaccessible internal language behaviors. On Tue, May 10, 2016 at 1:59 PM, Kevin

Re: Proposing a conditional assignment (or equals) operator

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