[swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Andrew Bennett]

Great proposal, I think it will clear up some mistakes. What happens when
it is only an override sometimes? For example:

protocol A {
    associatedtype Element
    func get() -> Element
}

extension A where Element: ArrayLiteralConvertible {
    func get() -> Element { return [] }
}

struct Example<T> {
    func get() -> T
}

Example does "override", but not always. I'm sorry, I couldn't think of a
good solution to this.

On Thursday, 28 April 2016, L. Mihalkovic via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> On Apr 27, 2016, at 9:56 PM, Erica Sadun <erica at ericasadun.com
> <javascript:_e(%7B%7D,'cvml','erica at ericasadun.com');>> wrote:
>
>
> On Apr 27, 2016, at 1:45 PM, L. Mihalkovic <laurent.mihalkovic at gmail.com
> <javascript:_e(%7B%7D,'cvml','laurent.mihalkovic at gmail.com');>> wrote:
>
> Inline
>
> Regards
> (From mobile)
>
> On Apr 27, 2016, at 9:31 PM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>
> On Apr 27, 2016, at 12:25 PM, Douglas Gregor <dgregor at apple.com
> <javascript:_e(%7B%7D,'cvml','dgregor at apple.com');>> wrote:
>
>
> On Apr 27, 20
>
>
> * If the latter, “override” is probably the wrong keyword because it’s not
> overriding anything in the common case of implementing a non-defaulted
> requirement.
>
>
> It would be pointless if it’s just satisfying a requirement. That’s why
>  introduced both keywords into the discussion. (And because I’m still being
> influenced by the “near miss” conversation.)
>
>
> One could always argue that should protocol definitions ever be allowed to
> contain default implementations ala-java default methods, the distinction
> between former and latter would go away, and it would be happy anticipation
> to have mandated *override* all along in all cases, ensuring that future
> default methods would not accidentally take precedence of current code or
> wind up being treated differently than other overrides.
>
>
> I would expect default implementations in protocol definitions to act
> exactly like protocol definitions in extensions from the Type point of view.
>
> From the protocol point of view, I would introduce the same override
> behavior to signal affirmative intent.
>
>
> ... so *override* seems like the right keyword choice for today, that
> would be future proof in case default methods ever make it in protocols
> (which might be a cheap partial answer to the 'what about mixins' question)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160428/ef5c66bd/attachment.html>