There's no technical issue with named imports besides the fact that it's difficult to emit them in our compiler in a way that fits incremental linking.

We'll eventually do it, but we don't consider that a priority. A JavaScript-only pass can probably optimize such things on its own and do the tree shaking anyway.

Thank you for your answer 👍

@sjrd Would it be acceptable to generate a and m env fields even for native classes? This would

• use already existing namespacing mechanisms to select sub-fields of imports.
• allow the required modules to be easily determined upon class construction (rather than relying on names like now).
• make the load spec entirely private to the class (not required, but nice addition).

The downside is that we'd hide the access behind a function. The alternative would be to make a and m methods or fields depending on whether the class is native or not. But the semantic difference this implies probably violates the IR spec.

I'd rather we used refined $i end fields so that they also include the top-level identifier. Then they can be shared across all classes that import that field, and we don't have an additional function.

For folks following this issue. There is discussion on #4010 (comment) to use namespace imports for module splitting. If that get's accepted, we'd probably close this issue as wontfix (unless there is strong reason to do this for non-SJS modules, but not for SJS modules).

Relevant discussion on gitter:

@gzm0

Yes, that is fair. But by fixing #3743, don't we acknowledge that "we need precise non-namespace imports"? At least the current reasoning in #3743 applies to any kind of import.

@sjrd

Not necessarily. Because internally, we already have dead code elimination. We eliminate a log of things that don't make it into modules at all. External dependencies don't have that luxury. For them, avoiding namespace imports can be more important.

So #4010 is less related to this than I initially thought.