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

[L. Mihalkovic]

> 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/20160427/176a8a9f/attachment.html>