Consider namespaces excluding optionals by default

[guybedford]

Another suggestion to try and work around the concern I raised at the last meeting, that might be worth working through regardless of outcome - treating deferred reexports as unavailable by default rather than available by default in namespaces.

To go through the semantics:

• There is still only one cached namespace object, and these optional names would be defined as throwing if access is attempted when they are not yet loaded / async ready.
• If any other importer in the graph had done an explicit import of one of these optionals (via import { optional } from 'foo') they would have driven execution already so that the namespace access for anyone else in the graph would then work.
• In addition, we could possibly even use a (non-keying) import attribute to also hint the optional for the namespace case - import * as foo from 'foo' with { optional ['optional'] }.

The hard failure is a rough edge still, but that is the same as import defer. Worth discussing nonetheless I think since it resolves the footgun question quite nicely by simply changing the default assumption.

[nicolo-ribaudo]

• In addition, we could possibly even use a (non-keying) import attribute to also hint the optional for the namespace case - import * as foo from 'foo' with { optional ['optional'] }.

Would this be equivalent to the following?

import { optional as ___unused } from "foo";
import * as foo from "foo";

The hard failure is a rough edge still, but that is the same as import defer.

A difference is that for import defer it is rare to see the hard failure (it can only happen with cycles), while with this approach it would be the default behavior.

[caiolima]

Such change would also means that adding an optional keyword in an re-export is going to cause an error when the optional entry is accessed through the namespace object. My major worry here is that the error is only going to happen at runtime, when an optional reexport is accessed. Such kind of late error have the potential to make the adoption of such feature very error-prone.

[nicolo-ribaudo]

From #24

@guybedford

My preferred behaviour here remains that by default we do not process all optional reexports, and instead only process those optional requests explicitly named.

The main reason for this is that import * does not just mean "import all", it also means "get the namespace object", which is a distinct use case from import all, and we see this with import(). So because semantically import all and namespace imports are conflated, we have this problem of asking for a namespace and getting the whole jungle as it were.

I think this is the remaining outstanding semantic question from my perspective.

I'd be happy to for this to land though of course with the caveat that this framing is still being worked out.

@acutmore

import * does not just mean "import all"

I feel like there is too much cultural precedence for this to be intuitive.

• export * from "./utils.js";
• SELECT * from table
• ls *
• from math import *
• use std::collections::*;

[acutmore]

From #24 (comment)

I feel like there is too much cultural precedence for this to be intuitive.

• export * from "./utils.js";
• SELECT * from table
• ls *
• from math import *
• use std::collections::*;

If taking this stance, then import('foo') should be deemed to be import * ('foo') and we have a language gap in the language for dynamic import that must be resolved before this proposal can proceed.

cc: @guybedford

I don't think that holds. An API/Syntax representing something does not mean it has to be the only way something is expressed.

* implying "everything" doesn't mean that Relect.allKeys is wrong and it should be Reflect.*Keys.

If we had import { a, b } as ns from "path"; I would also expect something like import("path", { bindings: ["a", "b"] }) and import(path, { bindings: "*" }) would be equivalent to import(path).

[guybedford]

To try and clarify my position here as much as possible.

There are two framings here:

1. import * as foo from 'foo' is a namespace import, and namespace imports do not include optionals. Then have a separate scheme for specifying which optionals are included (such as using import attributes).
2. import * as ns from 'foo' means import all (which is entirely reasonable), so will include optionals. Then we must solve the problem of partial imports for dynamic import() and partial execution for deferred imports using syntax or options.

(1) is what this issue is tracking, but (2) effectively requiring partial namespaces is a reasonable alternative.

In my opinion (1) is less work and a simpler approach requiring no new syntax, leveraging spec paths existing today. I'm perfectly ok with (2) though if that is preferred. But we must do either, and not neither.