SE-0260: Library Evolution for Stable ABIs

[Torust (Thomas Roughton)]

@Spencer_Kohan

As far as the opt-in nature of library evolution, I still think it makes sense to be able to opt out on a per-struct bases. It's not clear to me why libraries declaring datatypes to be consumed by the GPU and libraries using library evolution should be mutually exclusive.

There's precedent for this in other languages which IMO would map fairly naturally to Swift. For example, C# has the [StructLayout(LayoutKind.Sequential)] attribute, which could map to a @structLayout(sequential) attribute. Of course, this is largely a moot issue until the compiler's layout algorithm changes.

By the way, you currently can't map trivially to GPU structs in many cases because the struct's size isn't rounded up to the maximum alignment of the stored properties. Assuming a struct of the below format with Vec3 being an alignment-16 type,

@Spencer_Kohan

struct Vertex { 
  let position: Vec3 
  let normal: Vec3 
  let textureUV: Vec2 
}

the struct definition needs an extra let padding : Vec2 = Vec2(0) property at the end to make it compatible with GPU structs under the current layout algorithm.