> On Apr 27, 2016, at 9:56 PM, Erica Sadun <[email protected]> wrote:
>
>
>> On Apr 27, 2016, at 1:45 PM, L. Mihalkovic <[email protected]>
>> wrote:
>>
>> Inline
>>
>> Regards
>> (From mobile)
>>
>>> On Apr 27, 2016, at 9:31 PM, Erica Sadun via swift-evolution
>>> <[email protected]> wrote:
>>>
>>>> On Apr 27, 2016, at 12:25 PM, Douglas Gregor <[email protected]> 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)
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
