Discuss
  • [Harmony proxies] [[Construct]] semantics breaks the expectation of seeing an object as return value

[Harmony proxies] [[Construct]] semantics breaks the expectation of seeing an object as return value

# David Bruant (14 years ago)

In ES5.1 - 13.2.2 is defined functions instances [[Construct]]. As one can notice, it always returns something of type Object (as per ES5.1 - 8.6). Consequently, a call to "new A()" always reliably either returns an object or throws an exception.

Proxies semantics of [[Construct]] states that (step 5) the [[Call]] internal method of constructhandler should be called. It opens the door to returning things which are not objects (number, boolean, undefined, ...).

I can't think of precedents of this for host objects and I don't really see a use case in allowing "new A()" to return something else than an object

When writing functions intended to be used as constructors, people may be used of |this| being used as the to-be-returned object and expect this behavior even if defining a constructor.

So i would be in favor of adding a type check between step 5 and 6.

# Tom Van Cutsem (14 years ago)

I believe the relevant use cases here were value types/value proxies, which

  • if added in the future - would want their constructors to return non-object values. I searched the archives but can't seem to find the relevant threads, still, I'm sure it was discussed here previously.

Cheers, Tom

2011/9/23 David Bruant <david.bruant at labri.fr>

# David Bruant (14 years ago)

Le 23/09/2011 17:17, Tom Van Cutsem a écrit :

Hi David,

I believe the relevant use cases here were value types/value proxies, which - if added in the future - would want their constructors to return non-object values.

Interesting. So maybe it should be kept in mind to relax the current constraint of [[Construct]] having to return objects (unless types/value proxies are planned on being objects)