Built-in modules come up repeatedly around the various proposals. I am making this issue to centralize the discussion such that champions of the eventual proposal have a good central location for information. I will keep this up-to-date if there is further discussion in this issue.
Existing Discussion Syntax Options Naming convention inside module specifierThis option entails establishing a naming convention for built-in modules. Has to be compatible with existing ecosystems, eg. we cannot clobber an npm or standard node package name.
Strawman: *-sigil
import "*SIMD";
import {float32x4} from "*SIMD";
import SIMD from "*SIMD";
Strawman: URL scheme
import { float32x4 } SIMD from "std:SIMD";
Distinct syntax for built-in module imports
This option necessitates additional reflective capabilities in the Loader API to request built-in modules by name as opposed to going through the normal module resolution process.
Strawman: IdentifierName instead of StringLiteral
import SIMD;
import {float32x4} from SIMD;
import SIMD from SIMD;
Semantics Requirements
Must defer to loader to resolve built-in modules (important for polyfillability). Loader may see either a special string or possibly an options record indicating that a built-in module is requested.
AlicanC, fbender, BrendanEich, b-strauss, glen-84 and 8 more
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4