Can enums derived from BitwiseCopyable primitives be implicitly BitwiseCopyable

Using Swift
1

Currently, if I have enum:

enum Foo: Int8 {
    case a
    case b
}

It won't implicitly derive BitwiseCopyable and I should explicitly set it everywhere:

enum Foo: Int8, BitwiseCopyable {
    case a
    case b
}

I wonder if that would be okay to add BitwiseCopyable implicitly to such enums?

2

I can't reproduce the behavior you're seeing. This compiles for me in 6.3 and above:

enum Foo: Int8 {
    case a
    case b
}
func f<T: BitwiseCopyable>(_ x: T) {}
f(Foo.a)

EDIT: Is your enum public? That's called out explicitly by SE-0426:

Furthermore, when building a module, the compiler will infer conformance to BitwiseCopyable for any non-exported struct or enum defined within the module whose stored members are all BitwiseCopyable, except those for which conformance is explicitly suppressed.

But be careful of your expectations here. The bitwise representation of a raw-value based enum is not the same as its raw value; it's the enum's internal discriminator.

If I have this:

enum Foo: Int8 {
  case a = 50
  case b = 100
}

The bitwise representations of a and b are 0x00 and 0x01 respectively, not 0x32 and 0x64.

Likewise, the size of an enum may not be the same as its raw value. It's only as large as needed to hold the number of cases that is has:

enum Foo: Int32 {
  case a = 50
  case b = 100000
}
print(MemoryLayout<Foo>.size)  // 1, not 4

There is an exception to this: @c enums do have the same bitwise representation as their raw values.

7 Likes
3

Thank you for the quick answer.

Yeah, this one is public and I thought that this is safe for primitive types enums to forward BitwiseCopyable.
But okay - I can mark them all as BitwiseCopyable explicitly. Just was wondering the reasoning because I would await that for primitives to be automatic even for public types.

Yeah, I know but thank you for reminder.

I think you mean for exported C/C++ code but just in case:
Do you mean that there is a way to define C enum right in swift code?

4

Given that the : Int8 is (I believe) part of the ABI of the symbol when it is public, it is impossible to change the enum in a way that would make it non-bitwise-copyable, right? So I don’t see the harm for inferring BitwiseCopyable in this particular narrow case.

5

SE-0495 added the @c attribute, which can be applied to functions and enums. For enums, it exports it into the generated header and thus has the same bitwise representation as a C enum.

(I should have also mentioned @objc enum, which has the same result but has existed for even longer than the @c attribute.)

2 Likes
6

What would prevent a raw-value enum from being BitwiseCopyable even if its RawValue type is not? Since the enum is represented solely by an integer discriminator, it seems like it should always qualify as BitwiseCopyable.

7

There's no technical reason, but the language has moved in a direction where conformances like these are inferred for non-public types but required to be explicitly specified for public types. That's because these represent a contract, and we don't want to infer a conformance for something that's an exported API without the author being explicit about it.

The observation above that giving a public enum a raw type is a guarantee that it will always be bitwise copyable is true, but Swift already has quite a few subtly different inference rules for certain protocols and it's not clear that saving the user a little bit of typing is worth adding yet another special case that makes those rules harder to remember.

2 Likes