On Jun 12, 2014, at 11:30 AM, Jason Orendorff wrote:

> On Thu, Jun 12, 2014 at 10:06 AM, Domenic Denicola
> <domenic at domenicdenicola.com> wrote:
>> I'd be most interested in seeing if we can remove IsConstructor entirely (except for uses where it's just a guard, implementing the semantics of `new` via IsConstructor -> [[Construct]] or throw).
>> 
>> It seems like there's at least some movement toward removing it from `Array.of` and `Array.from`. All that remains is its use to preserve the `arrayInstance.constructor = undefined` backward-compatibility possibilities.
> 
> Proxies also observe it.
> 
> I *really* wish we just had an @@new for this, such that
>    new C(...args)
> is just shorthand for
>   C[Symbol.new](...args)
> and the construct trap could be removed from proxies altogether.  :-|

At TC39 meetings (and probably on some es-discuss threads) we've talked about eliminating [[Construct]] and simply inlining its ordinary definition (more or less: C.apply(C[Symbol.create](), args) ).  We didn't reach consensus to do so.  I believe that some of the concern was simply not knowing whether all of the DOM [[Construct]] semantics could be successfully replaced replaced using only @@create methods and constructor bodies.

Another possible concern is an exotic [[Construct]] can't be invoked any way other than using the new operator.  A @@create (or a hypothetical @@new) can be copied around and invoked from arbitrary places. This raises concerns about whether their might be security exploits that could be built upon them.

It's not obvious to me why we would need @@new in addition to @@create (which is pretty much equivalent to saying it's not clear to me why we need [[Construct]]). For the ordinary case, @@new would just be another level of method lookup and invocation that would be required on each new.  While we expect implementations to (eventually)  optimize all of this, we still tried to minimize the amount of boiler plate work required for each new. 

Allen

At TC39 meetings (and probably on some es-discuss threads) we've talked about eliminating [[Construct]] and simply inlining its ordinary definition (more or less: `C.apply(C[Symbol.create](), args)`).  We didn't reach consensus to do so.  I believe that some of the concern was simply not knowing whether all of the DOM [[Construct]] semantics could be successfully replaced replaced using only @@create methods and constructor bodies.

Another possible concern is an exotic [[Construct]] can't be invoked any way other than using the new operator.  A @@create (or a hypothetical @@new) can be copied around and invoked from arbitrary places. This raises concerns about whether their might be security exploits that could be built upon them.

It's not obvious to me why we would need @@new in addition to @@create (which is pretty much equivalent to saying it's not clear to me why we need [[Construct]]). For the ordinary case, @@new would just be another level of method lookup and invocation that would be required on each new.  While we expect implementations to (eventually)  optimize all of this, we still tried to minimize the amount of boiler plate work required for each new.