TC39 Structs and Shared Structs
2024-01-21
plaintext logs
prev next
source on github
01:06
<littledan>
though those restriction just as well applies to shared structs
Makes sense but do these things work with non-shared structs?
01:07
<littledan>
one idea that was raised was additional restrictions on methods declared within structs, like making them always throw on instances of different types, and making them unbindable (unrelated ideas)
Why is the unbindable restriction an optimization?
01:10
<littledan>
we have ideas there, but i kinda don't want them to lump those ideas into this proposal at the moment. namely, when i discussed with V8 staff, the sentiment was that explicit classes that don't change layout aren't necessarily more performant than hidden classes from a megamorphism POV, but we may have opportunities in layering additional restrictions on top to aid performance
The concern is often that some aspect of the restrictions “doesn’t necessarily” reduce hidden megamorphism; this seems true but I wonder how we could evaluate empirically the frequency of how much this helps (and maybe even compare vs, eg, type system features to encourage people to program a particular way)
01:25
<rbuckton>
Is this polymorphism so much more prevalent than argument polymorphism that it would even matter?
03:11
<littledan>
Is this polymorphism so much more prevalent than argument polymorphism that it would even matter?
I imagine that that is about being able to eliminate the map check in the first place, rather than polymorphism. Maybe this is what is meant by “binding” as well—calling with a different receiver?