IsConstructor

[Domenic Denicola]

A variety of places in the spec use the new IsConstructor abstract operation. In ES5, this test (essentially, "does the object implement the [[Construct]] internal method") was restricted to the `new` operator. But in ES6, it is used in implementing a large variety of built-in functions:

- All Array methods
- All %TypedArray% methods
- All Promise methods (via NewPromiseCapability)

(Note that there are two uses: arrays and typed arrays do alternative logic for non-constructors; promises fail immediately. This inconsistency might be a bug?)

It seems to me that we should expose this primitive reflective operation to users, instead of having all of these methods be able to detect something that user code can't, and thus making them harder to explain or polyfill.

Alternately, if we don't think users should be doing this kind of reflection, then we probably shouldn't be doing it ourselves. In which case, figuring out an alternate path for the above methods would be useful---perhaps they simply try to construct, and fail immediately if used with a non-constructible object, instead of falling back.

WDYT?