> The review of "SE-0080: Failable Numeric Conversion Initializers" begins now > and runs through May 9. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md
Hello, I'm all for it, but I'd like a clarification about... the Integer / Floating point interface. I once had to write a function that compares Int64 to Double for strict equality, with all the sweats that come whenever you deal with floating point representations and have to introduce two-complements representation of integers as a mandatory precondition: /// Returns true if i and d hold exactly the same value, and if converting one /// type into the other does not lose any information. private func int64EqualDouble1(_ i: Int64, _ d: Double) -> Bool { return (d >= Double(Int64.min)) && (d < Double(Int64.max)) && (round(d) == d) && (i == Int64(d)) } As I understand well the proposal, I could write instead: private func int64EqualDouble2(_ i: Int64, _ d: Double) -> Bool { guard let j = Int64(exact: d) else { return false } return i == j } But I may be wrong! The "without loss of information" in the proposal means that -0.0 (minus zero) would *not* be convertible to Int64 (which would lose the sign). And we'd get: int64EqualDouble1(0, -0.0) // true int64EqualDouble2(0, -0.0) // false No problem with that. To know if int64EqualDouble1 has a bug, or if int64EqualDouble2 should handle -0.0 explicitly, one needs to know how -0.0 should be handled. So I think that the proposal should make it very clear how it wants to handle all the funny Float and Double values. Without such a clarification, as handy as they look like, those functions would remain surprising, which means very hard to use well, and we'll keep on sweating. Gwendal Roué _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution