| 15:17 | <Ashley Claymore> | I’ve captured my reasoning about shared struct constructor and prototype registration, as I understand nicolo-ribaudo’s revelation, and how we expect shared struct semantics to compose or intersect with modules and evaluators, which would give users a level to designate a cohort of shared structs for purposes of evaluating some set of modules. https://gist.github.com/kriskowal/7f56e3bd5a634f1ca828fb3e571e3c7b new alfa() === new bravo();" surprised me, they are separately mutable so their bytes can diverge |
| 15:42 | <kriskowal> | That’s a thing I don’t know but suspected and expect to be corrected if inaccurate. |
| 17:47 | <Richard Gibson> | hmm, it is probably important for compatibility that primitive (i.e., typeof x !== "object" || x !== null) ⇒ immutable, and even more important that strict (in)equality is time-invariant |
| 17:51 | <shu> | yeah i wouldn't say shared structs are primitives, but exotic |
| 17:51 | <shu> | their prototype behavior is very similar to the prototype behavior of primitives |
| 17:51 | <shu> | but that doesn't imply that they are primitives |
| 18:06 | <kriskowal> | off hand, what’s the planned typeof a struct? |
| 18:06 | <kriskowal> | (i’ve removed the spurious claim) |
| 18:58 | <shu> | object |
| 18:58 | <shu> | shared structs are like exotic objects |
| 18:58 | <shu> | unshared structs, after the no-private-stamping integrity trait, can be explained as sealed objects with that additional trait (if we don't retcon sealed to also contain that trait), i think |