[swift-evolution] [Review] SE-0080: Failable Numeric Conversion Initializers

[Gwendal Roué]

> 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é