> 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
