[swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

Xiaodi Wu xiaodi.wu at gmail.com
Wed Jan 6 04:00:06 CST 2016


>Possible solution: if you want a new protocol adoption to map to some existing method or property then you must explicitly write that. You can't just adopt the protocol in an empty extension.
>
>    extension Int: BoundedType {
>        static var min = Int.min
>        static var max = Int.max
>    }
>
>but with some other syntax that isn't ambiguous. Code completion and compiler fix-its could suggest this when the class already implements something suitable.

That would be really neat. On my wishlist though would be something
along the same lines going in the forward direction, where there's
some sort of distinction between a class or struct overriding a
dynamically dispatched default implementation for a method declared in
a protocol and a method that doesn't override anything but happens to
'shadow' or 'mask' a statically dispatched method in a protocol
extension that's never fully overridden. I guess the objection here is
that a change in syntax for that scenario would make new protocol
adoptions after the fact difficult; but there must be a way to have it
both ways...


On Wed, Jan 6, 2016 at 3:48 AM, Greg Parker <gparker at apple.com> wrote:
>
>> On Jan 5, 2016, at 8:50 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>>
>>> Taking inspiration from syntax used for methods in classes that override methods in superclasses, require methods that override dynamically dispatched default implementations in protocol extensions to use the override keyword. Likewise, forbid the override keyword if the method being implemented instead 'masks' (would that be the right word?) a statically dispatched method in a protocol extension which can nonetheless be invoked by upcasting to the protocol.
>>
>> This has been suggested before, usually in the form of a separate `implement` keyword. The main problem is that it makes it impossible to write a protocol after the fact which formalizes some existing pattern in the types.
>>
>> What do I mean by that? Well, imagine you need generic access to the `min` and `max` static properties of the various integer types. There's no existing protocol that includes those members. But you can write one and then extend the integer types to conform to your new protocol:
>>
>>       protocol BoundedIntegerType: IntegerType {
>>               static var min: Self { get }
>>               static var max: Self { get }
>>       }
>>       extension Int: BoundedType {}
>>       extension Int8: BoundedType {}
>>       extension Int16: BoundedType {}
>>       extension Int32: BoundedType {}
>>       extension Int64: BoundedType {}
>>
>>       func printLowestPossibleValueOfValue<Integer: BoundedIntegerType>(x: Integer) {
>>               print(Integer.min)
>>       }
>>
>> This only works because `min` and `max` *don't* need any special marking to be used to satisfy a requirement. Requiring a keyword like you suggest would remove that feature.
>
> Possible solution: if you want a new protocol adoption to map to some existing method or property then you must explicitly write that. You can't just adopt the protocol in an empty extension.
>
>     extension Int: BoundedType {
>         static var min = Int.min
>         static var max = Int.max
>     }
>
> but with some other syntax that isn't ambiguous. Code completion and compiler fix-its could suggest this when the class already implements something suitable.
>
>
> --
> Greg Parker     gparker at apple.com     Runtime Wrangler
>
>


More information about the swift-evolution mailing list