> On May 2, 2016, at 9:44 AM, Tony Allevato via swift-evolution
> <swift-evolution@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
