Description
| Previous ID | SR-3726 |
| Radar | rdar://problem/34141063 |
| Original Reporter | @ematejska |
| Type | Task |
| Status | Resolved |
| Resolution | Won't Do |
Additional Detail from JIRA
| Votes | 0 |
| Component/s | |
| Labels | Task, AffectsABI |
| Assignee | None |
| Priority | Medium |
md5: 49f72855cd0ebf30564d52987c7d03f6
Issue Description:
Ahead of ABI stability, consider if tuple elements are bit-packed to save space.
Updated
This issue should track the overall data layout for tuples. Here is the relevant text from the ABI manifesto:
Tuples are similar to anonymous structs, but they differ in that they exhibit structural subtyping: a tuple of type e.g. (Bool, Bool) can be passed anywhere expecting generic types (T, U). But, the type (T, U) exists at a higher abstraction level than (Bool, Bool). Due to this, tuples may face more expensive reabstraction costs if their layout is aggressively packed. Reabstracting such a tuple would involve splitting and promoting each element into their own addresses.
This may be an argument for a simple, declaration-order, non bit-packed layout algorithm for tuples. Tuples are often used for small local values and rarely persisted across ABI boundaries in a way that aggressive packing is performance-critical. This would also be more consistent with how fixed-size C arrays are presented in Swift, which are imported as tuples.
We should investigate whether to aggressively bit-pack tuple elements similarly to structs, paying the reabstraction costs, or if the benefits are not worth the costs [SR-3726].
Tuples should be binary compatible between labeled and unlabeled tuples of the same type and structure.