| 01:24 | <sirisian> | Remind me. The built-in-modules proposal was never a fix for the name conflicts right? Forcing someone to ```import "@std/Object"; which would patch the Object using side-effects. Was it decided years ago to continue using global changes forever? |
| 01:26 | <voidhedron> | I think it would be nicer if instead we started having the prototypes of new builtins that get added to the language be frozen by default |
| 01:26 | <voidhedron> | then we can guarantee no issues of that sort in those new builtins |
| 01:29 | <bakkot> | sirisian: I don't believe anyone ever proposed having built-in module imports be side-effecting, no |
| 01:30 | <bakkot> | and the built-in modules proposal was never formally rejected IIRC but has certainly stalled, and we're not blocking stuff on it |
| 01:30 | <bakkot> | voidhedron: that would prevent polyfills of later features, so we're not going to do that |
| 01:31 | <voidhedron> | right... I didn't consider that |
| 01:32 | <voidhedron> | maybe if there was a more official streamlined way of creating and applying polyfills |
| 01:33 | <voidhedron> | and just polyfills, no other random stuff |
| 01:34 | <bakkot> | most people have gotten the memo about not adding random stuff now |
| 01:35 | <bakkot> | so anyone doing it anyway would presumably be willing to use whatever "official" mechanism there was |
| 01:42 | <voidhedron> | yeah it is way past too late for it to be helpful at this point, but if we had made something like: (and frozen prototypes) which validated the inputs given by running it through the relevant test262 tests and if it didnt pass it refused to apply the polyfill |
| 01:42 | <voidhedron> | we wouldn't have been in this situation now with web incompat issues |
| 01:43 | <voidhedron> | it would also have automatically managed the right property descriptor for each polyfill |
| 03:22 | <Ashley Claymore> | Some of the web compat bugs are because the polyfill isn't being applied. They were doing: if (![].groupBy) addGroupBy() |
| 03:23 | <Ashley Claymore> | it's better if they always unconditionally apply it, that way the sudden appearance of the official implementation doesn't change the behaviour of the site |
| 03:25 | <Ashley Claymore> | It was only old versions of sugarJs that were applying it conditionally. Sites using newer versions of sugarJS were unaffected |
| 03:34 | <voidhedron> | Yeah, that conditional application of the polyfill would also have been handled by the dedicated Polyfill api, so it would also have prevented that had it existed. |
| 07:46 | <nicolo-ribaudo> | Does anyone know why importing bindings that are not declared by a module throws a SyntaxError and not a ReferenceError? |
| 07:48 | <Jessidhia> | my guess is that it’s an error that happens before any code is executed |
| 07:52 | <nicolo-ribaudo> | That's what I suspected too — I am asking because some of the modules proposals allow distinguishing parsing errors from linking errors, so it's possible to detect "this is not actually a syntax error" |
| 19:48 | <bakkot> | https://twitter.com/sebmarkbage/status/1669410404001251333 |
| 19:48 | <bakkot> |
|
| 19:48 | <bakkot> | I don't hate this idea |
| 19:48 | <bakkot> | you can import a module for side effects; why not a script? |
| 20:09 | <nicolo-ribaudo> | I don't hate it either :) |
| 20:18 | <ljharb> | why should the type even be needed? |
| 20:19 | <ljharb> | like what's stopping it from Just Working |
| 20:58 | <nicolo-ribaudo> | You need somehow to decide if the loaded file should be evaluated as a script or a module |
| 20:59 | <nicolo-ribaudo> | Someone uses .mjs, others use how the file is imported |
| 21:09 | <bakkot> | sloppy mode :( |
| 21:09 | <bakkot> | also the different parsing for await in modules, which is just wack |
| 21:11 | <ljharb> | oh right, duh, ambiguous syntax |
| 21:11 | <ljharb> | it'd work fine in anything with a filesystem since it could use extensions, but not with something URL-based |
| 22:43 | <Michael Ficarra> | this is why we invented MIME types |
| 22:45 | <bakkot> | unfortunately html disagrees |
| 22:46 | <bakkot> | anyway you probably wouldn't want a MIME type to affect whether something was loaded as strict or non-strict |
| 22:46 | <bakkot> | that would be incredibly painful to track down |