Re: operator overloading proposal

@Isiah: Great points. One potential edge case though: ```js class A { operator+ (other) { } } class B { operator+ (other) { } } const a = new A(); const b = new B(); const c = a + b; ``` In the case where both the left and right side have `[[OpPlus]]` do we prefer the left side? >

Re: Tracking proposals should be standardized with issues

Sorry but this is confusing. So any employee of TC39 member organizations can be a champion? On Thursday, May 12, 2016, Domenic Denicola wrote: > From: es-discuss [mailto:es-discuss-boun...@mozilla.org ] > On Behalf Of G. Kay Lee > > > Unfortunately, the latest

RE: Re: Tracking proposals should be standardized with issues

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of G. Kay Lee > Unfortunately, the latest stage 0 proposal (Object enumerables), which is an > outside contribution (in [the > list](https://github.com/tc39/ecma262/blob/master/stage0.md) the column > header says "champion"

Re: Re: Tracking proposals should be standardized with issues

So I just took some time to look into existing contribution rules ([1]( https://tc39.github.io/process-document/) / [2]( https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md)) and it appears that TC39 members can come up with stage 0 proposals at will, while outside contributors need to go

Re: Re: Tracking proposals should be standardized with issues

> I haven't seen many proposals actually born in the ML, I've rather seen tons of proposals discussed offline and/or suddenly part of some repo/site/post/strawman. Yes you are so right. Just a few hours ago we have yet another new [stage 0

Re: Re: Tracking proposals should be standardized with issues

I understand, and mostly agree, with Isiah's concerns but, about this: > The higher barrier of entry helps filter most of that out other than here in the mailing list... I haven't seen many proposals actually born in the ML, I've rather seen tons of proposals discussed offline and/or suddenly

Re: Re: Tracking proposals should be standardized with issues

New proposals should be a repo. Any discussion or changes in the proposal should be centered in that repo. Those repos will be transferred to the TC39 org once they hit stage 1. That repo should include links to any relevant es-discuss threads. Old proposals may be mired in legacy wikis and

Re: Re: Tracking proposals should be standardized with issues

Here's my concerns: 1. People are going to blow up the issues they like, instead of either creating issues in those related repos or finding more appropriate channels for them. 2. People are going to start filling issues for whatever proposal they came up with, without really deliberating over

Re: Re: Tracking proposals should be standardized with issues

For those not aware of the "currently compiled list" he's referring to this https://github.com/tc39/ecma262 It has no clear history other than viewing the change log. I agree. Ideally every link on that page should link to an issue that tracks the information. This would allow for much cleaner

Tracking proposals should be standardized with issues

The issue tracker should have a labeled issue matching every proposal, so that it's possible to look through previous proposals and track their status, instead of just manually compiled lists of current proposals. Older proposals can essentially only be found by stumbling upon them, and their

Re: operator overloading proposal

That's the current state of things. I think the main issue at hand is ergonomics. Haskell, the MLs, and Swift solved it by allowing inline functions and operators as functions (that wouldn't work in a dynamic language). Scala solved it by magic methods for unary operations and the fact nearly

Re: operator overloading proposal

But, do we really need operator overloading? A method can be used instead, I think. 2016-05-11 8:53 GMT+02:00 Isiah Meadows : > Efficiency and optimization. If you're stupid enough to want to violate > those priorities in a public API, it's your own fault. But if you want

Re: operator overloading proposal

Efficiency and optimization. If you're stupid enough to want to violate those priorities in a public API, it's your own fault. But if you want to optimize updating a collection (i.e. zero allocation update for a persistent map) or increment a vector by another without having to create an

Re: operator overloading proposal

Why would you ever want to violate the algebraic properties of operators, such that `a += b` wasn't exactly equivalent to `a = a + b`, `a *= b` not equivalent to `a = a * b`, etc? I'm quite confident that any proposal that allowed for that would get tons of pushback. On Tue, May 10, 2016 at 11:26

Re: operator overloading proposal

1. Yes, they would be inherited, but not on the prototype itself (it would technically be parasitic). It would be modeled with internal slots, so that the properties are themselves immutable and transparent, so the only way to inherit would be via the class syntax or `Reflect.construct`. Engines