> On Feb 10, 2017, at 12:41 PM, Robert Ryan via swift-evolution > <[email protected]> wrote:
> I’m hard pressed to think of a situation where you’d want the current Swift 3 > behavior of the first example (where you can override a protocol default > implementation but you only want that override used when you reference the > class itself, but not when you reference the protocol as a type). Thats easy - the extension methods are not related to protocol conformance. The type implementing the protocol may not even know there *is* an extension method, or that method could be added either later or by yet other third party code. As such, the type may not be overriding the extension method at all - the protocol-implementing types may have their own method with a conflicting name doing similar (or not) logic. It would not be appropriate for someone calling the protocol extension method to get different behavior simply because a type declared a similar named method. In other words, without the method being declared on the protocol, override behavior between an extension and type would be similar to unsafe “duck” typing. There is no agreement by the type that they are conforming to extension behavior, only to the protocol’s behavior. IMHO the issue actually goes the other way - there is no way to indicate that an extension method to a protocol is meant to declare ‘default’ behavior, e.g. represents a partial implementation for types conforming to the protocol. - there is no way to indicate that a type property/method ‘implements’ the functionality of a protocol. The lack of a distinction between extensions declaring random methods and declaring default implementation behavior is obviously an element of confusion. Both points become an issue if the protocol method signatures ever changes - the extension could no longer be providing a default implementation, or a type may silently switch from their own implementation to the default implementation provided by the extension. -DW > If there are such examples, then add a “build setting” to allow you to turn > off this warning, or add some keyword to the declaration of the default > implementation that indicates that you’re allowing it to be overridden, but > protocol types won’t use it (e.g. nondynamic). Personally, I’d just add the > warning and call it a day (because I don’t know why you’d ever want the > current Swift 3 behavior). > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
