22

How bad would it be if we imported a C++ enum class with underlying type as if it were a resilient enum with unknown cases? At first glance, that strikes me as a reasonable balance. You'd still be able to semi-exhaustively match the formally-declared enum constants, though you'd need an @unknown default: fatalError() branch that might be boilerplatey. For enum classes that do get used as bitmasks or strong typedefs, you could still use the .init(rawValue:) and .rawValue members to create undeclared values of the enum classes.

3 Likes
23

That’s what it’s currently doing. The problem is that omitting @unknown default is only a warning, not an error.

24

Right, if it behaved as a resilient type, then leaving out the unknown default would be an error.

1 Like
25

That seems fine to me. We could also just promote the warning to error for C++ enums (and enum classes). Or is there something else we get from making it resilient?

26

That would be the most important semantic aspect. We don't want to literally compile it as a resilient type, of course, to avoid abstraction overhead.

27

Almost, the underlying type is unsigned char. Also, I feel like it'd be more correct to import C++ scoped enumurations (i.e. enum class) with no enumerations as something roughly equivalent to:

struct CPPEnum: RawRepresentable {
    typealias RawValue = cpp_underyling_type;
    var rawValue: RawValue
    init(rawValue: RawValue) {
        rawValue = rawValue
    }
}

Although it might be a bit tricky in this case since std::byte (but not any user defined scoped enums that are backed by unsigned char) is explicitly allowed to alias just as if it were unsigned char itself.