[SR-5267] Optional<Bool> layout is inefficient

[dabrahams]

Previous ID	SR-5267
Radar	rdar://problem/19859539
Original Reporter	@dabrahams
Type	Bug
Status	Reopened
Resolution

Additional Detail from JIRA

| | | |------------------|-----------------| |Votes | 0 | |Component/s | Compiler | |Labels | Bug | |Assignee | None | |Priority | Medium | md5: 0aefdbe4f7f07547cb62f2bd02f6a8c0

is duplicated by:

• SR-3725 Determine if struct data members are addressable or bit-packed

relates to:

• SR-3727 Determine the layout algorithm for payloaded enums

Issue Description:

I need to store a bunch of true/false/indeterminate values, but Swift doesn't handle it efficiently:

(swift) MemoryLayout<(Bool?,Bool?)>.size
// r0 : Int = 2
(swift) MemoryLayout<(Bool?,Bool?,Bool?)>.size
// r1 : Int = 3
(swift) struct X { var a, b, c: Bool? }
(swift) MemoryLayout<X>.size
// r2 : Int = 3

These should all fit in one byte.

[dabrahams]

@swift-ci create

[belkadan]

There are sort of two parts here:

• Bool could be bit-packable.

• Enum discriminators could be bit-packable.

(And making Bool an enum would collapse these two problems into one…)

[jckarter]

Enum discriminators are already bit-packed; Bool? takes two bits. Tuples are constrained by the (T,T,T) abstraction boundary, so we can't bit-pack their fields unless we're willing to reabstract them at generic boundaries. We could conceivably bit-pack concrete structs.

[bob-wilson]

I'm reopening this. I redefined SR-3726 to track the larger task of defining the layout algorithm for tuples, not just whether they are bit-packed. Let's use this report to track the packing issue.