| 16:45 | <leobalter> | littledan: I'm not a big fan of trailing comma in the import conditions for `import()` |
| 16:45 | <leobalter> | https://github.com/tc39/proposal-import-assertions/pull/77/files#diff-3540caefa502006d8a33cb1385720803R38 |
| 16:46 | <leobalter> | idk, it looks like an approach to make it similar to function calls, but it distorts from what we have today from other expressions |
| 16:46 | <leobalter> | like void and typeof |
| 16:47 | <leobalter> | it is not a big deal, but I definitely need to take it with a grain of salt |
| 16:48 | <leobalter> | and while I see some motivation for function calls leaving a trailing comma, I don't see many for import, it's too specific and cannot really be monkey patched. |
| 16:51 | <ljharb> | it's the same motivation |
| 16:51 | <devsnek> | i think import calls should always have had trailing commas |
| 16:51 | <ljharb> | note that webpack requires special comments between `import(` and the specifier, and people often write them multiline - `import(\n\t/* webpack magic */\n\tspecifier\n)` |
| 16:52 | <ljharb> | and by allowing a trailing comma, you minimize git diffs when adding or removing the import assertions - minimizing diffs imo is the motivation for trailing commas anywhere |
| 16:52 | <ljharb> | +1 to `import()` should always have allowed trailing commas |
| 17:23 | <littledan> | hopefully it's not a problem that we don't allow leading comments! |
| 17:24 | <littledan> | leobalter: I could go either way on trailing commas for import assertions, personally |
| 17:24 | <littledan> | I was persuaded by the argument devsnek and ljharb make above that really, all calls should have this |
| 17:25 | <leobalter> | as I said, I need to accept this with a grain of salt |
| 17:28 | <leobalter> | the motivations are not good enough for me, but shipping this little awful part is a better goal won't cause me harm on everyday usage or get me stuck on future code. |
| 17:28 | <devsnek> | what is the comparison to void and typeof |
| 17:29 | <leobalter> | they are all expressions like import |
| 17:29 | <devsnek> | I mean what do they have to do with trailing commas |
| 17:29 | <leobalter> | they don't have a usage format with trailing commas |
| 17:29 | <devsnek> | neither does addition |
| 17:30 | <leobalter> | are you devaluaing my subjective point of view? Even when I say I'm ok with this "feature"? |
| 17:31 | <devsnek> | no I'm trying to understand it |
| 17:31 | <leobalter> | I'm not sure where we can go from here |
| 17:31 | <devsnek> | I just don't understand what parallel there is between void and import in the context of trailing commas, and I wanted to understand it |
| 17:32 | <leobalter> | they are all expressions |
| 17:32 | <devsnek> | you can join expressions with commas |
| 17:32 | <devsnek> | is that what you're saying? |
| 17:32 | <leobalter> | not function calls, even if they look like function calls |
| 17:32 | <devsnek> | void looks like a function call? |
| 17:32 | <devsnek> | oh do you mean |
| 17:33 | <leobalter> | `void(0)` |
| 17:33 | <devsnek> | void (x)? |
| 17:33 | <devsnek> | ok now I understand |
| 17:33 | <devsnek> | do people actually do that |
| 17:59 | <bradleymeck> | devsnek: typeof(x) is seen enough for me to be familiar with |
| 19:12 | <ljharb> | littledan: in the first position of `import()`? they're surely allowed |
| 19:12 | <ljharb> | littledan: "any expression" is allowed there |
| 19:13 | <ljharb> | leobalter: `super()` allows trailing commas: `class C extends Object { constructor() { super(3,); } }` |
| 19:13 | <ljharb> | leobalter: `import()` is exactly like `super()`. |
| 19:13 | <ljharb> | (as opposed to being like typeof/void) |
| 19:15 | <leobalter> | in my brain, super takes arguments. These arguments are arbitrarily-picked by the developer. Where the import() is an expression without args but a specific notation of settings. |
| 19:17 | <leobalter> | it's subjective. It's weird that we came so long with `import(x)` not being a function that even empty args are invalid syntax |
| 19:17 | <ljharb> | to me, `import()` is conceptually calling a function, just like `super()` is, and import assertions makes that even more true |
| 19:17 | <littledan> | I meant, you can't do `import(\n\t/* webpack magic */,\n\tspecifier\n)` |
| 19:17 | <ljharb> | also tho, `void` and `typeof` are not function-like at all; `super()` and `import()` are. |
| 19:17 | <littledan> | it was a joke; I don't think this is up for debate |
| 19:17 | <ljharb> | littledan: without the comma you can :-p |
| 19:17 | <littledan> | heh yes |
| 19:18 | <ljharb> | lol k |
| 19:18 | <leobalter> | nit: `import()` itself is a syntax error |
| 19:18 | <ljharb> | indeed, that is true |
| 19:18 | <leobalter> | and extend this to `import(/* magic */)` |
| 19:20 | <leobalter> | consistency w/ Arguments is not a strong argument for me here (puns not intended) as we can never be completely consistent. |
| 19:21 | <leobalter> | in any case, I'm not trying to block and I'm not insisting for us to change this. |
| 19:21 | <leobalter> | I personally don't like it |
| 19:22 | <littledan> | we could just permit Arguments in `import()` |
| 19:22 | <littledan> | and just ignore it if people give too many ,and cast from undefined if people give too few |
| 19:22 | <leobalter> | I'd prefer if this could be separate from Import Assertions, but not worth all the hassle |
| 19:22 | <littledan> | I agree that these changes aren't worth much hassle one way or another |
| 19:24 | <rkirsling> | what if...we made `()` a value |
| 19:24 | <rkirsling> | oops this isn't TDZ |
| 19:25 | <leobalter> | I'm not sure what optimization do we want that prevents us from going with: `import Arguments`. Releasing a lot of static errors that are exclusively to `import()` |
| 19:26 | <leobalter> | we could benefit from something like: |
| 19:26 | <leobalter> | const settings = [specifier, opts]; |
| 19:26 | <leobalter> | import(...settings); |
| 19:28 | <littledan> | I think there was some logic that, if import is a keyword, it shouldn't have call-like syntax |
| 19:28 | <littledan> | I don't really get that argument |
| 19:29 | <littledan> | I'd be fine to break out a separate PR to change the syntax of `import() `to take arbitrary Arguments |
| 19:33 | <leobalter> | A PR for that should be relatively easy. I’d probably ask if we want empty arguments as valid too. |
| 20:02 | <ljharb> | since empty arguments will *always* be a bug, detectable only asynchronously, why would we want to allow it? |
| 20:02 | <ljharb> | same with spreading an empty array |
| 20:03 | <ljharb> | i don't think 100% consistency is more important than providing reasonable things everyone expects, like trailing commas, and prohibiting harmful things nobody expects to be permitted |