[swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

[Brent Royal-Gordon]

> It does privilege the left-hand side of a binary operator, but I think that’s acceptable for the operators we’ve seen in practice. (Of course we would need real data to back that up.)

I'm not quite so convinced that privileging the left side isn't a big deal—think of all the mandatory type checks and other chicanery in an `-isEqual:` implementation—but I wonder if we can avoid privileging the left-hand side at all. For instance, suppose use of an infix operator "looked" like this:

	(lhs, rhs).==()

And method dispatch on a tuple was defined to use the dynamic types of all members of the tuple, with some kind of multimethod dispatch system. Then both operands participate equally in the dispatch, and a case with disparate subclasses will fall back to a superclass.

	// Note: This is, admittedly, an incredibly funky syntax.
	protocol Equatable {
		extension <T: Equatable>(T, T) {
			func ==() -> Bool
		}
	}

	class Car: Equatable {
		let vin: String
	}
	extension (Car, Car) {
		func ==() -> Bool {
			return self.0.vin == self.1.vin
		}
	}
	
	class Taxi: Car {
		var cabNumber: String
	}
	extension (Taxi, Taxi) {
		func ==() -> Bool {
			return self.0.cabNumber == self.1.cabNumber
		}
	}
	
	class Uber: Car {
		var driverID: Int64
	}
	extension (Uber, Uber) {
		func ==() -> Bool {
			return self.0.driverID == self.1.driverID
		}
	}

	// Note that I'm erasing the subclasses here.
	let taxi: Automobile = Taxi()
	let uber: Automobile = Uber()

	taxi == taxi	// Compares by cabNumber
	uber == uber	// Compares by driverID
	taxi == uber	// Compares by vin

Multimethod dispatch at runtime is relatively slow, but it *would* give us the exact behavior we want.

-- 
Brent Royal-Gordon
Architechies