| 18:28 | <bakkot> | looks like compile-time imports for wasm are going to ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/zww0CT9PRVw/m/YmtNkC4jAQAJ |
| 18:28 | <bakkot> | was there ever a strategy worked out for integrating that with the source-phase imports proposal? |
| 18:43 | <littledan (PTO until September 16)> | Source phase imports give you a WebAssembly.Module instance, so then you can instantiate it with that |
| 18:57 | <nicolo-ribaudo> | was there ever a strategy worked out for integrating that with the source-phase imports proposal? |
| 19:16 | <guybedford> | Wasm ESM integration will specify that string builtins is enabled for instance & source phase, Luca Casonato mentioned this at our update at the last plenary meeting |
| 19:20 | <bakkot> | Source phase imports give you a WebAssembly.Module instance, so then you can instantiate it with that .compile time when you'd want to enable it |
| 19:20 | <bakkot> | Wasm ESM integration will specify that string builtins is enabled for instance & source phase, Luca Casonato mentioned this at our update at the last plenary meeting |
| 19:22 | <bakkot> | presumably also any other built-ins? at least those which don't add capabilities? (which, IIUC the intention is for them to never add capabilities) |
| 19:22 | <guybedford> | I believe the intention is for them not to introduce capabilities under compile-time builtins, and that those are better suited as instantiation imports |
| 19:23 | <guybedford> | but we will have to see how things progress too |
| 19:23 | <guybedford> | perhaps a future compile time import could "pull in" an instantiation import |
| 19:23 | <guybedford> | to represent the capability boundary |
| 19:23 | <guybedford> | (I'm not sure I'm just hypothesising) |
| 19:24 | <guybedford> | at the very least, we can consider proposals on a case by case basis, and should ensure this feedback is part of any future builtins though |
| 19:27 | <bakkot> | that would be a nice way of doing it, yeah |