Closed chrysn closed 7 months ago
bbaldino
commented
7 months ago Personally I think mask-on-write feels better: it feels quite surprising to have a uX whose internal state "violates" its advertised size and, as we've seen a couple times, that incorrect internal state seems prone to "leaking" and causing issues.
bbaldino
commented
7 months ago @chrysn looks like @Kijewski is good with mask-on-write...any thoughts from your side? Your post makes a pretty compelling argument for it as well, I'd say :) If we're good to move forward maybe you can respond to my comment in https://github.com/rust-ux/uX/pull/65 so we can keep that going. Also, maybe you can reply to my question about the releases here ?
bbaldino
commented
7 months ago @chrysn ping :)
chrysn
commented
7 months ago It is decided then: We go to mask-on-write, and start committing to it.
So far, uX has not made any public promises that I'm aware of about its internal representation, other than its storage size and alignment being that of that of the next larger u{2^n}. It's a good property to have, and while I encourage https://github.com/rust-ux/uX/pull/65 that switches the implementation from mask-after (i.e. unused bits may have either value) to mask-before (i.e. all unused bits are 0), that has been an implementation detail we can switch around.
This issue tracks whether we want to accept changes that would fix uX's behavior to either side. That would narrow our possibilities, but we're not aiming for infinity, so that may be fine. So far I know of these effects:
I think that the structural integrity match makes a pretty convincing case to decide mask-before, so if we'd vote I'd vote for committing to mask-before, but I don't want to decide that alone by encouraging-and-approving a public form of #65.
So, @rust-ux/crates, shall we?