Rick Waldron waldron.rick at
Wed Jun 11 07:58:33 PDT 2014

On Wed, Jun 11, 2014 at 10:24 AM, Domenic Denicola <
domenic at> wrote:

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

I had similar questions a couple years ago and Allen advised that the
easiest polyfill for such a mechanism is:

function isConstructor(C) {
  try {
    new C();
    return true;
  } catch (e) {
    return false;

Additionally, at the July 2012 tc39 meeting I proposed (over breakfast) an
ES7 "standard library module" that exported the abstract operations that
are now defined in chapter 7,
the response was positive but it was far too early to have a serious
discussion. Anyway, with that you'd just write:

import { isConstructor } from "es-abstract";

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list