Implement a type layout algorithm

[kyouko-taiga]

See also: #1065

We should implement a layout algorithm for generation the binary representation of types with a record layout. We should probably use the same algorithm as Swift.

• Start with a size of 0 and an alignment of 1.
• Iterate through the fields, in element order for tuples, or in var declaration order for structs. For each field:
  • Update size by rounding up to the alignment of the field, that is, increasing it to the least value greater or equal to size and evenly divisible by the alignment of the field.
  • Assign the offset of the field to the current value of size.
  • Update size by adding the size of the field.
  • Update alignment to the max of alignment and the alignment of the field.
• The final size and alignment are the size and alignment of the aggregate. The stride of the type is the final size rounded up to alignment.

[dabrahams]

An algorithm like this leaves it up to the user to find the most efficient arrangement of fields. We should discuss whether we want to do that.

[kyouko-taiga]

We can mix and match different approaches, like Rust does. I think some users will want to be able to predict the layout of their types to implement low-level shenanigans. So I guess we'll need a way to accommodate this use case anyway. For example, Data in Swift's standard library is relying on a predictable layout algorithm.

Of course we can say that the user is only allowed to make assumptions about type layout if their type is marked with @snowman, even if we have only one eager layout algorithm for the time being.

[dabrahams]

Please, Data is in Foundation!😉Sent from my iPhoneOn Oct 10, 2023, at 10:00 AM, Dimi Racordon @.***> wrote: We can mix and match different approaches, like Rust does. I think that users will want to be able to predict the layout of their type to implement low-level shenanigans. So I guess we'll need a way to accommodate this use case anyway. For example, Data in Swift's standard library is relying on a predictable layout algorithm. Of course we can say that the user is only allowed to make assumptions about type layout if their type is marked with @snowman, even if we have only one eager layout algorithm for the time being.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>