| 20:03 | <bradleymeck> | ruh roh |
| 20:03 | <bradleymeck> | export {no_no_no_no_no as await}; |
| 20:03 | <bradleymeck> | did await as an identifier not have a strict mode angry ban in that specific location? |
| 20:04 | <ljharb> | why would it? |
| 20:04 | <ljharb> | it's a valid identifier outside of an async function |
| 20:05 | <ljharb> | altho that may actually present a problem for TLA, lol |
| 20:05 | <bradleymeck> | not in module? you can't do `var await =` in a module |
| 20:05 | <ljharb> | oh no, nvm, because of the space |
| 20:05 | <ljharb> | are you sure? you can in strict mode. |
| 20:06 | <bradleymeck> | yes, await is reserved |
| 20:06 | <ljharb> | hm, ok |
| 20:06 | <ljharb> | so you can't `import { await } from './mod'`? |
| 20:06 | <ljharb> | or i guess you might be forced to rename it |
| 20:06 | <ljharb> | in which case the export is "fine" for some value of fine |
| 20:07 | <bradleymeck> | yea... i guess but its... weird |
| 20:08 | <ljharb> | so is `then` as an export name |
| 20:09 | <bradleymeck> | then only is weird due to how people consume it |
| 20:09 | <ljharb> | exactly like `await`, then :-) |
| 20:09 | <bradleymeck> | this is an id that can be exported but no var can be named that |
| 20:09 | <bradleymeck> | so on both ends it is strange |
| 20:09 | <bradleymeck> | though, honestly i wish we would just allow arbitrary string names when renaming anyway... |
| 20:11 | <ljharb> | you can have a named export `yield` too |
| 20:11 | <ljharb> | probably all the reserved words |
| 20:11 | <ljharb> | but i mean, if you have to do `as` to export it then it seems reasonable to have to do `as` to import it |
| 20:13 | <bradleymeck> | not all of them, but its weird |
| 20:13 | <bradleymeck> | https://tc39.es/ecma262/#sec-exports-static-semantics-early-errors |
| 20:13 | <bradleymeck> | it only checks the names of the bindings? not what they are renamed to? |
| 20:15 | <ljharb> | hmm, https://tc39.es/ecma262/#prod-NamedExports says `IdentifierName as IdentifierName` |
| 20:16 | <ljharb> | and that early error says "For each IdentifierName n in ReferencedBindings of NamedExports" |
| 20:16 | <bradleymeck> | import side DGAF about what you grab |
| 20:16 | <ljharb> | "ReferencedBindings" seems to restrict it to the LHS of the as |
| 20:16 | <bradleymeck> | wait... :thinking: |
| 20:21 | <bradleymeck> | well some things blow up if you put bad things on the RHS it seems |
| 20:30 | <bradleymeck> | i think somethign might be impl wrong (everywhere?) cause i can export `package` but it looks like no engine lets me import it... |
| 20:30 | <ljharb> | even renamed? |
| 20:31 | <ljharb> | that's fascinating, you could presumably get it off the namespace |
| 20:31 | <bradleymeck> | correct https://tc39.es/ecma262/#sec-identifiers seems like package should be a banned rename |
| 20:31 | <bradleymeck> | since RHS of export with the rename needs an identifier |
| 20:31 | <bradleymeck> | and identifier should exclude reserved word |
| 20:31 | <bradleymeck> | oh, but we are using IdentifierName not identifier... |
| 20:31 | <ljharb> | right |
| 20:31 | <bradleymeck> | :stare: |
| 20:32 | <bradleymeck> | import uses IdentifierName too, but no one allows it to be a reserved word |
| 20:35 | <ljharb> | so is that a bug in engines, they should be allowing it? |
| 20:36 | <ljharb> | sounds like a job for some test262 tests |
| 20:38 | <bradleymeck> | yea they should be allowing it *grumbling* |
| 20:40 | <bradleymeck> | honestly given that... why aren't we allowing arbitrary string names? |
| 20:40 | <bradleymeck> | export {x as "why not"}; |
| 20:42 | <ljharb> | yeah that's a fair question |
| 20:44 | <bradleymeck> | `export {_ as this}` is now my favorite |
| 20:47 | <ljharb> | a module with only reserved words as exports, plus "then", so that the only way you can ever import it is synchronously as a namespace |
| 21:01 | <bradleymeck> | i'm particularly curious about this given JSON could have any key represented as a string |
| 21:17 | <Bakkot> | in my parser "export { a as await }` and `import { await as b } from ''` are legal |
| 21:17 | <Bakkot> | also with s/await/if/ or whatever |
| 21:17 | <Bakkot> | could've sworn there were test262 tests for this |
| 21:18 | <shu> | i ran into `as` exports the other day |
| 21:18 | <shu> | it's quite confusing, there was an incorrect test262 test about named exports that happened to be named "default" |
| 21:18 | <bradleymeck> | `this` works in both positions, but `package` and the ilk in that section are odd |
| 21:19 | <Bakkot> | how so? |
| 21:19 | <Bakkot> | that is, if they're odd in the spec in that position, how are they odd? |
| 21:20 | <bradleymeck> | implementations don't like you importing that name |
| 21:20 | <bradleymeck> | spec says you should be allowed to `import {package as _}` |
| 21:21 | <bradleymeck> | even more fun, abstract module record doesn't have any restrictions on exported names |
| 21:21 | <bradleymeck> | pretty sure that could come back to bite things |
| 21:22 | <Bakkot> | seems to work fine in node? |
| 21:23 | <Bakkot> | let b = 0; |
| 21:23 | <Bakkot> | export { b as package }; |
| 21:23 | <Bakkot> | import { package as a } from './import-reserved.mjs'; |
| 21:23 | <Bakkot> | node --experimental-modules import-reserved.mjs import-reserved.mjs |
| 21:23 | <Bakkot> | works fine |
| 21:25 | <ljharb> | Bakkot: don't even need the flag in 13.7+ |
| 21:26 | <bradleymeck> | Bakkot: didn't work in the browsers i just tried mmm |
| 21:27 | <Bakkot> | bradleymeck: works fine in Chrome |
| 21:28 | <Bakkot> | also Firefox |
| 21:28 | <Bakkot> | did you get the order of the `as` things backwards? |
| 21:28 | <Bakkot> | (also safari) |
| 21:28 | <bradleymeck> | maybe i did do a typo |
| 21:28 | <bradleymeck> | or its the darn service workers |
| 21:28 | <bradleymeck> | :stares at local dev: |
| 21:29 | <devsnek> | it should be any valid IdentifierName |
| 21:29 | <devsnek> | `export { a as function }` |
| 21:30 | <bradleymeck> | thats a good one |
| 21:30 | <devsnek> | if that isn't valid in an engine its a bug |
| 21:32 | <devsnek> | the idea about allowing string literals there is interesting though |
| 21:32 | <devsnek> | i'd be in favor |
| 21:34 | <bradleymeck> | i think either allowing everything or constraining would be fine, but right now it is in an odd place |
| 21:35 | <devsnek> | it seems fairly consistent to me atm |
| 21:36 | <devsnek> | i would actually worry that allowing strings would make people confuse it for a property name and they might write `x as [y]` or something |
| 21:36 | <bradleymeck> | well right now abstract module records can export arbitrary names |
| 21:36 | <bradleymeck> | so it isn't like other languages can't export these |
| 21:37 | <devsnek> | wasm is the most glaring |
| 21:37 | <devsnek> | its imports and exports are utf8 strings |
| 21:43 | <devsnek> | actually that's an argument to allow export as "string", so you can interop with modules expecting those exports |
| 21:44 | <bradleymeck> | yea probably |
| 21:45 | <bradleymeck> | well i think thats more pertinent than "from 'foo' import" so maybe we can swap that agenda item out |
| 21:48 | <ljharb> | i'd just add both but tell the chairs that that one is low priority |
| 21:48 | <bradleymeck> | yea |
| 21:48 | <devsnek> | we should probably set aside a few hours for export as string, very high priority |
| 21:48 | <bradleymeck> | i somewhat doubt it breaks more than a hour given that wasm already can do it |
| 21:49 | <devsnek> | oh yeah i was kidding lol |
| 21:49 | <devsnek> | i'd assume 30 minutes at most |
| 21:49 | <devsnek> | you can also mention commonjs |
| 21:50 | <bradleymeck> | we are still arguing if we can support CJS named exports at all I thought? people were hesitant about a static analysis approach and pretty negative towards the other ones |
| 21:54 | <devsnek> | bradleymeck: generated esm wrappers can use it |
| 21:55 | <bradleymeck> | fair enough |
| 22:04 | <bradleymeck> | https://github.com/tc39/agendas/pull/748 |
| 22:05 | <bradleymeck> | spec text wouldn't be too hard |