Edge case enum

[xwu (Xiaodi Wu)]

@jrose

Still without reading the guarantees, my concern is that text that is not normalized will be normalized differently in a future version of Unicode.

My read of the guarantees—I could be wrong—is that this is explicitly what Unicode states will never happen.

According to the Unicode policy for Normalization Forms, applicable to Unicode 4.1 and all later versions, the results of normalizing a string on one version will always be the same as normalizing it on any other version, as long as the string contains only assigned characters according to both versions.

(Source: UAX #15)

---

@jrose

But even the unassigned case is bad: if I use an older compiler to work with some just-added emoji, and then update my compiler, the code could stop compiling. (Or it’s just a warning, as long as there’s a way to silence the warning.)

The code that would stop compiling after the update would be an enum you created containing cases with string raw values that are different representations of the same just-added emoji: and it can't be just any new emoji sequence, but would have to be one with new emoji codepoints; and the new emoji codepoints would have to compose with each other or have a "strongly discourage[d]" new composition with an existing codepoint.

Which, I mean, you can contrive to do in theory—although, now that I reflect, I'm actually not aware of any emojis which have decomposed and composed codepoint counterparts introduced in the same Unicode version, so in fact I'm not sure you could actually contrive this in practice—but (a) it's nigh impossible to do by accident; and (b) as it is, the behavior of an enum with non-unique raw values is un(der?)specified, so not compiling it after you update your compiler would be arguably an improvement?

[xwu (Xiaodi Wu)]

@michelf

I think the most surprising thing here is not that the compiler is allowing the enum to exist, but that a == b is equivalent to a.rawValue == b.rawValue. I would have expected the comparison to be based on the discriminant, not the raw value.

Comparing the raw values can make the comparison more expensive, especially with strings, and it can make the result different based on runtime considerations, like the version of Unicode used.

As I recall, this is already tracked as a bug.

[tera]

@michelf

I think the most surprising thing here is not that the compiler is allowing the enum to exist, but that a == b is equivalent to a.rawValue == b.rawValue.

However I do not see EQ on rawValues being called when comparing enumeration constants in another example with a custom expressibleByXXXLiteral enumeration:

Edit: I've been corrected below.

Quite elaborate setup (any way to simplify it?)

struct C: ExpressibleByIntegerLiteral, RawRepresentable {
    typealias RawValue = Int
    var rawValue: RawValue
    init(rawValue value: RawValue) {
        rawValue = 0 // let's ignore value
    }
    init(integerLiteral value: RawValue) {
        rawValue = 0 // let's ignore value
    }
    init() {
        rawValue = 0
    }
    static func == (lhs: Self, rhs: Self) -> Bool {
        print("EQ \(lhs) and \(rhs)")
        return true
    }
    var hashValue: Int { 0 }
}

enum E: C {
    init?(rawValue: C) {
        fatalError("unused")
    }
    var rawValue: C {
        switch self {
        case .x: return C(rawValue: 1)
        case .y: return C(rawValue: 2)
        }
    }
    
    case x = 1, y = 2
}

var x = E.x
var y = E.y
print(x.rawValue == y.rawValue) // true, EQ called
print(x == y) // false, EQ not called

[jrose (Jordan Rose)]

C has to be Equatable, which yours isn’t. (And C doesn’t need to be RawRepresentable, which yours is.)

[tera]

You are absolutely right!

Corrected code

struct C: ExpressibleByIntegerLiteral, Equatable {
    var value: Int
    init(integerLiteral value: Int) {
        self.value = value
    }
    init(value: Int) {
        self.value = value
    }
    static func == (lhs: Self, rhs: Self) -> Bool {
        print("EQ \(lhs) and \(rhs)")
        return true
    }
    func hash(into hasher: inout Hasher) {
        hasher.combine(0)
    }
}

enum E: C {
    case x = 1, y = 2
}

var x = E.x
var y = E.y
print(x.rawValue == y.rawValue) // EQ C(value: 1) and C(value: 2), true
print(x) // x
print(y) // y
print(x == y) // EQ C(value: 1) and C(value: 2), true !!!

Indeed comparing enumeration constants compares rawValues instead of discriminators

[tera]

@xwu

As I recall, this is already tracked as a bug.

Do you mean this one or another?

[sveinhal (Svein Halvor Halvorsen)]

@tera

Found the equivalent edge case that doesn't use Strings and behaves exactly the same way:

enum F: Double {
    case x = -0.0
    case y = 0.0
}

I expected — and tested — for this exact case yesterday, but found that the compiler did give an error Raw value for enum case is not unique. So I shrugged and decided not to share that finding here.

However, I now see that I tried to express

enum Number: Double {
    case a = 0
    case b = -0
}

Maybe not surprising, but I was surprised that -0 and -0.0 are parsed differently, when type isn't inferred to be Int. It seem -0 is first parsed as an Int and then converted to a Double?

[tera]

Yep, tis is a known feature, -0 is treated as integer zero and then converted to double zero, whilst -0.0 is treated as negative double zero.

print(Double(-0).sign)  // plus
print((-0.0).sign)      // minus

Another known issues are that '+0' or '+0.0' or '-(0)' or '-(0.0)' is not a literal expression and that '0.0 == 0.0' and '0.0 < 0.0' is ambiguous.

[tera]

Another class of oddball enums is related to floating point overflow:

enum E: Float {
    case x = 0xCp127 // Warning: '0xCp127' overflows to inf during conversion to 'Float'
    case y = 0xCp128 // Warning: '0xCp128' overflows to inf during conversion to 'Float'
}
print(E.x.rawValue == E.y.rawValue) // true
print(E.x == E.y) // true
print(E(rawValue: .infinity)!) // x

Perhaps it should be an error instead of a warning.

[tera]

Thank you, the unknown hero who fixed enums comparisons recently.

func testDoubleEnum() {
    enum E: Double {
        case a = 0.0
        case b = -0.0
    }
    print("E.a == E.b ->", E.a == E.b)
    print(".a ~= E.a ->", .a ~= E.a)
    print(".b ~= E.a ->", .b ~= E.a)
}
func testStringEnum() {
    enum E: String {
        case a = "\u{00c0}"
        case b = "\u{0041}\u{0300}"
    }
    print("E.a == E.b ->", E.a == E.b)
    print(".a ~= E.a ->", .a ~= E.a)
    print(".b ~= E.a ->", .b ~= E.a)
}
testDoubleEnum()
testStringEnum()

I could now see it working as expected on nightly builds of godbolt.

I assume it will be officially available in Swift 6.3. Thank you!

[dnadoba (David Nadoba)]

While I’m somewhat in favor of this change as I would like the perf improvement of this, I don’t think this has been changed intentionally and this is really a bug.

I’m especially suspicious because hashValue is still equal for .a and .b which shouldn’t be the case if this would have been truly “fixed”: Compiler Explorer

[tera]

Good find. I'd say that hash values being equal is a bug.. just that!

The values are different, that rawValues are the same should not make a difference. You are right, the hashes are better be different for different enum cases.

Perhaps the enum's hashValue should be based solely on the discriminator (and the associated values if any) and not take the case's rawValue into account.

[jrose (Jordan Rose)]

(Just in case, remember that it’s acceptable for hashes to be the same when content is different, just not ideal. It’s the opposite that’s fully breaking.)

[Nobody1707]

I've often wondered if we could clean up unary operators in numeric literals in a future language version, or if we're just stuck with this.

[tera]

@Nobody1707

I've often wondered if we could clean up unary operators in numeric literals in a future language version, or if we're just stuck with this.

You mean + specifically or an arbitrary prefix operator?

---

IMHO Swift could benefit from some simple constant expression folding done at compile time, (without investing into full tilt const expressions), for example:

enum E: Int {
	case a = +123
	case b = -2*(3+4)/5
}

i.e. "zero syntax cost" const expressions, perhaps with a very limited subset of allowed operators.

[Nobody1707]

I meant both unary + and - . I don't believe any of the others are special cased like that.