TC39 General
2022-12-01
plaintext logs
prev next
source on github
01:29
<ljharb>
tolmasky: what's the use case? it might be relevant for the get-intrinsic proposal :-)
06:07
<sirisian>
Is there a new cancelable promise proposal? Was going through and refreshing myself on proposals and noticed the last one was withdrawn recently.
06:32
<Jessidhia>
To wit, if we renamed module to something like moduleInstance, it would also make sense to use moduleInstace {} as the introducer for module expressions.
for some reason this started looking like an F# computation expression to me
06:39
<Jessidhia>
That’s not what they do, that’s what the modules are.
IIUC, the objection you’re making here is more on the grounds of, for example, import * as foo from './foo.css' with { type: 'css' } having the capability of foo being a different module record than import * as foo from './foo.css' with { type: 'cssmodule' } despite the URLs being equal?
09:08
<ljharb>
Jessidhia: yes, exactly right - the spec for assertions forbids those from being a different module record.
10:48
<Justin Ridgewell>
We can enforce that at the bundler level as well
15:06
<tolmasky>
If I change an intrinsic object (for example, Array.prototype), is it technically not "the" intrinsic anymore. Like if I do Array.prototype.cheese = 10, then in a hypothetical world where I did GetIntrinsic("Array").prototype (or GetIntrinsic("Array.prototype"), would I get back the object with the cheese property, or would it try to give me a "fresh" object?
17:16
<ljharb>
tolmasky: it is still the same intrinsic object. it has the same identity.
17:17
<ljharb>
"intrinsic" describes its state at the birth of the realm; the state doesn't matter after that