[swift-evolution] [Proposal] Instance Operators

[Adrian Kashivskyy]

I like the idea of moving operator implementations to the inner scope of a type, but I think this proposal doesn't cover all that is needed.

My main concern are infix operators – your proposal assumes that infix operators will always be implemented with the source on the left-hand-side:

> public operator * (rhs: Self) -> Self

My second concern is the internal operator symbol names:

> __operator__GreaterThanOrEqual

How should the compiler generate the name for below operator if it translates `>=` to `greater than or equal`?

> infix operator <**$$**>>



Pozdrawiam – Regards,
Adrian Kashivskyy

> Wiadomość napisana przez Haravikk via swift-evolution <swift-evolution at swift.org> w dniu 04.03.2016, o godz. 23:49:
> 
> Actually that’s what I was referring to; the difficulty is how to convert existing implementations of an equals operator into the new format, which means we’d probably have to just remove it from Equatable, require an equals() method then force developers to update their code.
> 
> i.e- if someone already has:
> 
> 	func == (lhs:MyType, rhs:MyType) -> Bool { /* Do some stuff */ }
> 
> It’s not clear whether it would be safe just covert that into an equals() method, removing the lhs parameter and replacing it with references to self instead. It might just be one of those changes that has to break code, but will be better in the long-run.
> 
>> On 4 Mar 2016, at 21:53, davesweeris at mac.com wrote:
>> 
>> Why not do it the other way around, like this?
>> func == <T: Equatable> (lhs: T, rhs: T) -> Bool {
>> 	return T.equals(lhs, rhs)
>> }
>>> On Mar 4, 2016, at 3:40 PM, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> ...
>>> This should be relatively simple to implement since in many ways we’re actually just getting rid of a feature, though of course the impact on code is more complex and probably not an easy one to convert automatically (as it would mean somehow pulling global == declarations into a local .equals() method and similar on affected types).
>>> 
>>> But I think in the long run it’s a cleaner system, and offers all the flexibility we need.
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160309/fe475cac/attachment.html>