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

[Howard Lovatt]

I like Greg Parkers suggestion, if the extension is of a type that is not
part of the project/library that is being developed then you don't need
override. This would allow after-the-fact extensions to library and
third-party structure/classes. It is also not confusing to human or
compiler, since this is not source code you are looking at (by definition).

On Thursday, 7 January 2016, Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Jan 6, 2016, at 3:48 AM, Greg Parker via swift-evolution <
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>
>
> On Jan 5, 2016, at 8:50 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','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.
>
>
> Another option might be to allow imported definitions to be used by a
> conformance without the `override` marking to support retroactive modeling
> while requiring definitions in the same module as the conformance to
> explicitly specify the `override`.
>
>
>
> --
> Greg Parker     gparker at apple.com
> <javascript:_e(%7B%7D,'cvml','gparker at apple.com');>     Runtime Wrangler
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>

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