| 01:00 | <kriskowal> | Thanks for the notes. |
| 01:02 | <kriskowal> | (Hard no on a registry from me, fwiw.) |
| 01:03 | <kriskowal> | What’s the key differentiator between import weak vs import defer or import source? |
| 01:54 | <Richard Gibson> | IIUC, weak indicates that a module (or presumably a related entity in the case of e.g. source) should be returned if already available but otherwise the barest of stubs should appear in its place. It's like an opportunistic ESM analog of old-school feature testing. |
| 02:07 | <jakebailey> | The definition we were working with was "if resolution fails, return undefined", so more "optional" than anything |
| 02:13 | <kriskowal> | That is interesting because it could apply at finer granularity of individual bindings, syntactically like import type in ts |
| 02:16 | <kriskowal> | Could be virtualized by allowing importHook to return undefined instead of throwing |
| 02:17 | <kriskowal> | Or tolerating the exception if weakly imported. “optional import” as it were |
| 02:18 | <kriskowal> | Or optionality could be indicated as we do elsewhere in destructuring with an explicit default |
| 02:45 | <jakebailey> | Yeah; the difference between the "deferred" import is that a deferred import will still error if the resolution fails, before anything else even happens. In that sense I prefer the term "optional" for clarity, especially given "weak" has existing connotations elsewhere |
| 02:45 | <jakebailey> | Though I honestly can't remember what a "source" import is. |
| 03:35 | <kriskowal> | Source imports are for grabbing a handle on the compiled source and not executing, to pass it to a worker, multiply instantiate, or isolate in another evaluation context (think mocks, dsls, or sandboxes) |
| 03:35 | <jakebailey> | Gotcha 🙂 |
| 09:43 | <Chengzhong Wu> | the term "weak" sounds strongly relevant to memory management to me. How abot "import optional"? |
| 09:47 | <nicolo-ribaudo> | try import |
| 09:47 | <nicolo-ribaudo> | Since it's suppressing an error |
| 09:50 | <Rob Palmer> | I think that "weak" could be fully understood by module experts such as those in this room and is an appropriate name for the proposal. To the wider world, I don't think it conveys "ability to tolerate failure" in the way that other words could, so maybe not good as a language keyword. Others that might work:
|
| 09:52 | <Rob Palmer> | maybe import ns as * from "this-might-not-exist"; |
| 09:53 | <Rob Palmer> | attempt import ns as * from "this-might-not-exist"; |
| 09:53 | <Rob Palmer> | (I am joking about leading with it, but the sentence like nature is cute) |
| 09:54 | <Chengzhong Wu> | import optional_or_try nil from "nil" might be easier to be parsed by toolings than optional_or_try import nil from "nil" |
| 09:56 | <Rob Palmer> | If we had from "mod" import x all of this would go away and we could have from "mod" try import x |
| 09:57 | <Chengzhong Wu> | from "mod" try import x reads different meaning to me... it could mean optional export names... |
| 10:19 | <nicolo-ribaudo> | suffix vs. prefix, my first impression is that try is a keyword, so try import is fully unambiguous and doesn't even require NLT restrictions |
| 14:55 | <joyee> | maybe import looks cute….bonus points if there can be a named exports syntax using with ? :) |
| 14:59 | <bakkot> | I kind of like "fallible imports" but it is a moderately obscure word |
| 16:20 | <ljharb> | that's not what try does, though :-) catch is what suppresses errors, try just makes them catchable |
| 16:22 | <kriskowal> | Strawpoke: import * as x = {} from “x” |
| 16:36 | <nicolo-ribaudo> | that's not what `try` does, though :-) catch is what suppresses errors, try just makes them catchable try import "foo" catch (e) { console.log("Failed importing foo") } :P |
| 16:37 | <ljharb> | right. it's the catch that does it tho, as you can see by using try finally (which would have to work with any try import keyword, too) |
| 16:40 | <joyee> | Throwing on error feels like repeating the issue that URL.parse() tries to solve (compared to new URL()) |
| 17:51 | <littledan> | import { foo } from.? "bar"; |
| 17:52 | <littledan> | import?. { foo } from "bar"; |
| 17:52 | <littledan> | (there are not serious suggestions) |
| 17:54 | <kriskowal> | Strawpoke: import * as foo = {} from "bar"; import foo = {} from "bar"; import { foo = {} } from "bar"; import bar = {}, { baz = {}, qux } from "foo"; Where in the last, we expect "foo" to load but don’t expect it to export bar and baz, but do expect it to export qux. |