> On Apr 27, 2016, at 12: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] <mailto:[email protected]>> wrote:
>
>> On Apr 27, 2016, at 12:25 PM, Douglas Gregor <[email protected]
>> <mailto:[email protected]>> wrote:
>>>
>>> On Apr 27, 2016, at 10:10 AM, Erica Sadun <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>>
>>>> From the Swift Programming Language: Methods on a subclass that override
>>>> the superclass’s implementation are marked with override—overriding a
>>>> method by accident, without override, is detected by the compiler as an
>>>> error. The compiler also detects methods with override that don’t actually
>>>> override any method in the superclass.
>>>>
>>>> I would like to extend this cautious approach to protocols, forcing the
>>>> developer to deliberately override an implementation that’s inherited from
>>>> a protocol extension. This would prevent accidental overrides and force
>>>> the user to proactively choose to implement a version of a protocol member
>>>> that already exists in the protocol extension.
>>>>
>>>> I envision this as using the same `override` keyword that’s used in class
>>>> based inheritance but extend it to protocol inheritance:
>>>>
>>>> protocol A {
>>>> func foo()
>>>> }
>>>>
>>>> extension A {
>>>> func foo() { .. default implementation … }
>>>> }
>>>>
>>>> type B: A {
>>>>
>>>> override required func foo () { … overrides implementation … }
>>>> }
>>>
>>> A couple questions about your pitch:
>>>
>>> 1) What is “required” doing there?
>>
>> I threw it in not because I’m tied to it but because I wanted it to be part
>> of the conversation.
>> This is a requirement from conforming to the protocol.
>>
>>> 2) Is “override” only required when there is a default implementation of
>>> the protocol requirement, or is it required whenever you are implementing a
>>> protocol requirement?
>>
>> Override is only because it is overriding the default implementation of the
>> protocol requirement. Without that default implementation there would be no
>> override, it would simply be satisfying the requirement.
>>
>>> * If the former, it might be the case that it’s too easy to forget to
>>> add the “override” keyword (because it’s needed for some implementations of
>>> protocol requirements but not others), which undercuts the value of having
>>> it.
>>
>> Forcing the override keyword makes it clear at the definition point that the
>> story extends beyond the method or whatever to point to a default
>> implementation that is being replaced. I *really* like having that reference
>> in terms of both code construction (“I am doing this as a deliberate act”)
>> with the compiler complaining otherwise, and in terms of code self
>> documentation (“I know this was added deliberately, what default did it
>> override?”)
>>
>>> * 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,
I fully expect this will happen someday. It would have happened when protocol
extensions were introduced except that the implementation was a bit more
involved than we had time for.
> 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.
Please spell out the scenario you are talking about.
- Doug
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
