inconsistent rules for operator overloading in swift - swift

Question

I'm seeing a strange difference in the way swift will overload + vs >:
protocol Value {
func get() -> Float
mutating func set(to:Float)
}
extension Float : Value {
func get() -> Float {
return self
}
mutating func set(to value:Float) {
self = value
}
}
func + (a:Value, b:Value) -> Float {
return a.get() + b.get()
}
func > (a:Value, b:Value) -> Bool {
return a.get() > b.get()
}
let a:Float = 1
let b:Float = 2
let c:Float = a + b //this works fine. Compiler calls Float + Float
let d = b > a //this causes infinite loop. Compiler recursively calls Value > Value
Any idea why the swift compiler is treating these cases differently?

Answer 1

The difference is that the standard library currently has a + overload defined directly on Float:
// TODO: These should not be necessary, since they're already provided by
// <T: FloatingPoint>, but in practice they are currently needed to
// disambiguate overloads. We should find a way to remove them, either by
// tweaking the overload resolution rules, or by removing the other
// definitions in the standard lib, or both.
extension ${Self} {
#_inlineable // FIXME(sil-serialize-all)
#_transparent
public static func + (lhs: ${Self}, rhs: ${Self}) -> ${Self} {
var lhs = lhs
lhs += rhs
return lhs
}
// [...]
}
(where ${Self} will be substituted by Float, Double & Float80 upon gyb.py running)
When it comes to overload resolution, a (Float, Float) -> Float overload of + will win over a (Value, Value) -> Float overload when applied with Float operands, as the latter will require them to be converted from Float to Value.
However Float doesn't have a > overload defined directly on it; it's instead defined as a top-level generic function over FloatingPoint operands:
#_transparent
public func > <T : FloatingPoint>(lhs: T, rhs: T) -> Bool {
return rhs.isLess(than: lhs)
}
When it comes to overload resolution, your (Value, Value) -> Bool overload will win over this generic overload as overload resolution favours non-generic overloads (see the tangent in my answer here). Therefore you'll wind up recurring. You could fix this by making your overload of > generic over <T : Value>(T, T) -> Bool, but then it would no longer be applicable to heterogenous Value operands.
Assuming you want the operators to be applicable to heterogenous operands, one foolproof solution would be to dispatch the calls to > and + via Float's conformance to Numeric and Comparable by using nested generic functions. This can't recurse because neither (Value, Value) -> Float nor (Value, Value) -> Bool can satisfy the + and > requirements of these respective protocols.
func + (lhs: Value, rhs: Value) -> Float {
func add<T : Numeric>(_ lhs: T, _ rhs: T) -> T {
return lhs + rhs
}
return add(lhs.get(), rhs.get())
}
func > (lhs: Value, rhs: Value) -> Bool {
func greaterThan<T : Comparable>(_ lhs: T, _ rhs: T) -> Bool {
return lhs > rhs
}
return greaterThan(lhs.get(), rhs.get())
}
(Note we're doing this for + as well as >, as the + (Float, Float) -> Float overload may be removed in favour of a generic overload, which would cause the same problems as with >)
Another solution would be to avoid dispatching to > and + altogether, and instead just call the isLess(than:) method on Float and the += operator, mimicking the stdlib implementations:
func + (lhs: Value, rhs: Value) -> Float {
var lhsFloat = lhs.get()
lhsFloat += rhs.get()
return lhsFloat
}
func > (lhs: Value, rhs: Value) -> Bool {
return rhs.get().isLess(than: lhs.get())
}
Though the calling of += may be problematic if you implement an overload of it for (inout Value, Value) -> Void.