Proposal: consider an alternative name from `defer`

[guybedford]

It could help understandability of the semantics of this proposal to more clearly disambiguate import defer from export defer given that they are semantically very different proposals.

I think if anything, considering these as optional reexports would most closely capture the semantics that are specified in an intuitive way to understand what is going on.

To list some of the confusions that could be resolved with renaming:

• export defer sounds like the export will execute sometime later on, when in fact it only might execute.
• import * as foo contains optional entries that only execute when used, and as such will defer deferred reexports. On the other hand, I might have imagined only import defer * as foo would be needed to get the deferred values for an export defer. Considering them as optional more clearly explains why there is no relation here.
• export defer * from 'foo' sounds like it might work based on syntactical symmetry, when in fact it is unsupported and likely never will be supported by this proposal. An export optional * from 'foo' is less likely to be assumed to work by symmetry of syntax here, once one understands that optionals are always named upfront.

In addition, this could more clearly align the proposal with the suggestion in #16.

[nicolo-ribaudo]

• export defer sounds like the export will execute sometime later on, when in fact it only might execute.

Note that this is already the case for import defer, as the import defer by itself does not schedule the execution of the deferred module. The main difference is that with export defer in many cases it is guaranteed that it will not execute (unless you use dynamic imports), while import defer means that it can actually happen (even if later).

• import * as foo contains optional entries that only execute when used, and as such will defer deferred reexports.

By "deferred reexports" here you mean would would be "optional reexports"?

• export defer * from 'foo' sounds like it might work based on syntactical symmetry, when in fact it is unsupported and likely never will be supported by this proposal. An export optional * from 'foo' is less likely to be assumed to work by symmetry of syntax here, once one understands that optionals are always named upfront.

I agree, this was what I disliked the most about the decision about using defer for both. (edit: I was thinking about export defer * as ns vs export optional * as ns)

[acutmore]

export defer * from 'foo' sounds like it might work based on syntactical symmetry, when in fact it is unsupported

Any misunderstanding here is very short lived due to it being a syntax error. It is clearly not supported even if someone might assume that it is and try it.

Editors could offer two quick fixes, one that expands it out to explicitly list all the names and another that asks for a single name to do export defer * as name.

[theScottyJam]

I tend to agree that the same name for the two is somewhat confusing. Given the current naming, if module A were to import module B (and for this example, no one else imports module B), then I would expect a deferred export from B to behave the same as a deferred import from A, the only difference is which end of the module loading relationship I'm declaring that it should be deferred.

That's at least what I would expect in my mind - maybe the thought process doesn't make as much sense for others.

[nicolo-ribaudo]

That is already kind of what's happening, when using namespace imports.

In these two examples (just moving the defer keyword):

// A
import defer * as B from "B";
B.foo;

// B
export { foo } from "C";

// A
import * as B from "B";
B.foo;

// B
export defer { foo } from "C";

Execution of C is deferred until the property access. Execution of B is different, because in the former case you are deferring the while import of B while in the second only the re-export of C