tracking issue for data enum prototype

[alejandro-vaz]

prototype for having RawSmallVec as an enum and not using TaggedLen

first implementation: https://github.com/alejandro-vaz/smallvec

anyone who wants to implement their own prototype as well is welcome

[bolshoytoster]

Won't this almost certainly increase the size of SmallVec? In your prototype, [u8; 16] takes 32 bytes, where it takes 24 in the current implementation. I don't think the compiler can do niches here.

The current implementation is basically what we'd want this to compile down to, just written explicitly.

[alejandro-vaz]

not in that particular case, but it can in many

[u8; 16] would be 32 bytes as you say, but [u8; 15] is 24 back again

but it can do other stuff like fitting [NonZeroU8; 16] in 24 bytes

overall it doesn't seem to matter much because it's just in these niches, it's not "it always needs 8 bytes more"

the advantage is that it's a simple integer lookup and has a clearer representation and it is sometimes faster overall and impossible to get wrong

it's just a prototype, we are not committing to anything

[bolshoytoster]

[u8; 16] would be 32 bytes as you say, but [u8; 15] is 24 back again

After some more testing, I've found that it's only bigger when the array's (byte) size is a multiple of 8 (probably quite common).

I've also noted that yours is actually smaller (16 bytes v 24) when the array's size is 0 (probably not very common)

but it can do other stuff like fitting [NonZeroU8; 16] in 24 bytes

Can it? I thought enums could only be niched if they only had one variant with data (like Option).

the advantage is that it's a simple integer lookup and has a clearer representation and it is sometimes faster overall

It would be interesting to see the benchmark results for this, since you're avoiding a bitmask, but in the cases where you need to get the discriminant and the length, this would require reading 2 ints from memory instead of 1.