[swift-evolution] [Proposal] Instance Operators

[Haravikk]

> On 25 Feb 2016, at 23:11, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I think this is a direction we want to go in, but how does this work for unary operators with a non-object type, and binary operators with a non-object LHS?

These could still use the global form of the operator; actually that does raise the point though that perhaps it shouldn’t be deprecated as suggested in the proposal, but instead we should just encourage the instance form for structs and classes?

> As DavidW said, it's important to figure out what this means for classes. (Don't forget asymmetrical operations within a class hierarchy, i.e. `A() == B()` vs. `B() == A()`.)

How big a problem is this in practice? Java for example just requires you to provide an equals() method, and actually that method takes an argument of Java’s Object type which is even more vacuous, but I never really found it to be problematic. In fact, thinking back on it I’m surprised that I didn’t.

Could we possibly provide some means of making an operator flippable? i.e- if in your example B extends A, the compiler would ensure that B, the more specific type, is always on the left hand side? Otherwise, while we can use is to test inheritance from a particular type, is there a way to test whether something is a sub-class? For example, we could implement operators such as:

	class Foo {
		func == (rhs: Foo) -> Bool {
			if rhs isSubClassOf Foo { return rhs == self }
			...
		}
	}

Is that currently possible or would it require a new feature? Thought that would be better if the comparison could be made against Self (as sub-classes that don’t override the operator could produce horrible loops).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160225/f3cc307b/attachment.html>