That proposal doesn't mention how the union struct handles tearing under concurrent modification.
Tearing can cause memory safety issue. Variant A can have an integer field and variant B can have a reference field in the same offset. Tearing can cause it to treat an integer as reference.
I’m the author of the original issue — I agree, we’ll have to ensure the struct layout is solved. I think the only thing that makes sense is to just waste a little space and store the fields side-by-side. In almost all cases where people would use a struct I think this is an acceptable tradeoff.
At the point where you have more than 5 cases, the GC overhead starts to get shrink in comparison to the calling convention and copying overhead anyway.
Will there be any layout optimizations performed by Roslyn for fields that can be aliased? E.g.: for a type union which has variants with 2 object fields and one ushort-sized at most each, have a base layout of (object, object, short)?
The design is not going to allow for struct layout to have memory safety issues when tearing is involved. That is a problem we are very well aware of and consider in designs.
Tearing can cause memory safety issue. Variant A can have an integer field and variant B can have a reference field in the same offset. Tearing can cause it to treat an integer as reference.