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

[Andrew Bennett]

Sorry, I sent too early. Example should have been:

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

My mistake does bring up another question. What if it only conforms after
the method is defined, in another module?

extension Example: A {}

On Thursday, 28 April 2016, Andrew Bennett <cacoyi at gmail.com> wrote:

> 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
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>
>>
>>
>> On Apr 27, 2016, at 9:56 PM, Erica Sadun <erica at ericasadun.com> wrote:
>>
>>
>> On Apr 27, 2016, at 1:45 PM, L. Mihalkovic <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> wrote:
>>
>> On Apr 27, 2016, at 12:25 PM, Douglas Gregor <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/a23f4f79/attachment.html>