Ecma262: Why are AsyncFunction et al not exposed?

[annevk]

On the HTML host side we've been moving away from having classes that are not exposed on the global object. @littledan mentioned ECMAScript has some of these, e.g., AsyncFunction. GeneratorFunction and Generator were also brought up by @bathos.

Is there a principle behind this that host environments would be encouraged to follow? Or was this done to be able to course-correct (the HTML host side has done some of that)?

[rwaldron]

Back in November 2012, the committee agreed to expose all of these new "?Function" constructors via standard module of some, yet unknown, form: The prototype/constructor object model supporting Generators/use of instanceof with generators and generator instances

[ljharb]

Assume it's accessible at System.Global

It sounds like the intention was to make it directly accessible but not global, but no mechanism has yet materialized to do that.

I think it’d be fine to make all of them global, personally.

[allenwb]

AS I recall, two reasons circa 2012:

1. avoid minimizing global name space with bindings for infrequently used references to what is essentially meta state. For cases where they are really needed there are other ways to access them.
2. The need to access to them is rare so giving them names makes them attractive nuisances.

The expectation in 2012 was that we would eventually make them more directly accessible via built-in modules. Still seems like the correct approach to me.

[ljharb]

@annevk this seems answered; if so, it seems like the paths are to either close it, or file a needs consensus PR (or create a proposal). Thoughts?

[littledan]

Maybe leaving it open for a little bit will encourage someone to pick up the issue? This is not a new feature request but a continuation of expected TC39 work.

[ljharb]

@littledan do you mean, writing a PR to expose them as globals? If so, that sounds great, and I'll update the labels.

If the conclusion is, "not as globals, but via built-in modules" then I think this should be closed in favor of an issue filed on the builtin modules proposal.

[littledan]

I don't think we reached a conclusion.