Decide mask-before vs. mask-after for public interfaces

[chrysn]

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 #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:

• If we decide mask-before:
  • We can use structural identity (Cannot pattern match #66)
  • We can tell the compiler that those bits are niches (Add niche optimization  #49)
• If we decide mask-after:
  • No concrete issues.
• If we decide neither-is-public:
  • We can infinitely explore

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?

[bbaldino]

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]

@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 #65 so we can keep that going. Also, maybe you can reply to my question about the releases here ?

[bbaldino]

@chrysn ping :)

[chrysn]

It is decided then: We go to mask-on-write, and start committing to it.