[swift-evolution] [Proposal] Improving operator requirements in protocols

[Chris Lattner]

> On May 2, 2016, at 9:44 AM, Tony Allevato via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I've written a proposal to formalize some of the discussion that was had over in the thread for the `FloatingPoint` protocol proposal regarding improvements to operator requirements in protocols that do not require named methods be added to the protocol and conforming types. Thanks to everyone who was participating in that discussion!

This is really great, thank you for pushing forward on this Tony!  I am really optimistic that this will allow us to finally put to rest the weirdness we have with protocols and operators.

> When a protocol wishes to declare operators that conforming types must implement, we propose adding the ability to declare operator requirements as static members of the protocol:
> protocol Equatable {
>   static func ==(lhs: Self, rhs: Self) -> Bool
> }
This sounds great.  Operators are clearly “static" members, and adding the keyword here is great for consistency when you end up *implementing* an operator inline in a class.  At that point, you want to see in the source where it is a “static” operator or a “class” operator (dynamic dispatch).

You don’t include it as part of your proposal, but I’d strongly suggest that we deprecate and/or remove the existing non-static operator requirement syntax.  I really don’t like ending up in a situation where we have both “instance” and “static” operators, where these two cases have different declaration and use syntax.

> Then, the protocol author is responsible for providing a generic global trampoline operator that is constrained by the protocol type and delegates to the static operator on that type:
> 
> func == <T: Equatable>(lhs: T, rhs: T) -> Bool {
>   return T.==(lhs, rhs)
> }
> Types conforming to a protocol that contains static operators would implement the operators as static methods
> 
They can also be ‘class’ methods in a class.

-Chris

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