[swift-evolution] Keyword for protocol conformance

[Xiaodi Wu]

On Fri, Aug 26, 2016 at 1:45 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> On Fri, Aug 26, 2016 at 1:27 PM, Charles Srstka <cocoadev at charlessoft.com>
> wrote:
>
>> On Aug 26, 2016, at 11:02 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>>
>> Really? I wasn't aware that you could work around the `override` keyword
>> (the one that's required for classes). How do you do that?
>>
>>
>> By implementing the subclass’s method before the superclass’s. You can
>> try this yourself:
>>
>> - - - Library code: - - -
>>
>> open class Superclass {
>>     public init() {}
>>     public func foo() {
>>         print("foo called in library")
>>     }
>> }
>>
>> - - - App code: - - -
>>
>> import FooLibrary
>>
>> class Subclass: Superclass {
>>     func bar() { print("bar called in the app") }
>> }
>>
>> let obj = Subclass()
>>
>> obj.foo()
>>
>> - - - output: - - -
>>
>> *foo called in library*
>> *Program ended with exit code: 0*
>>
>> - - - - - -
>>
>> Now: Change the library code to:
>>
>> open class Superclass {
>>     public init() {}
>>     public func foo() {
>>         print("foo called in library")
>>         bar()
>>     }
>>
>>
>>     // Hey look, I didn't even use that stupid new 'open' keyword.
>>     public func bar() { print("bar called in library") }
>> }
>>
>> - - - Run the app again without compiling it, and: - - -
>>
>> *foo called in library*
>> *bar called in the app*
>> *Program ended with exit code: 0*
>>
>> - - -
>>
>> Voilà: I overrode a method (a supposedly non-overridable one, at that)
>> with no “override” keyword.
>>
>
> This is clearly a bug in the implementation, not part of the design.
> Expect it to be fixed as the code for `open` matures. It's certainly not a
> precedent to be emulated for designing another feature.
>

I misread your example. You have to run the app *without compiling*; your
two versions of the library have a compatible ABI. The Swift compiler won't
compile your app code, so how's that an example of "working around"
anything in the language?

Just as File A in your earlier example can implement a protocol method
>> without realizing it, Subclass here has unintentionally overridden a
>> superclass method. This is because ‘override’ does not, to the best of my
>> knowledge, mean anything to the actual machine code that is produced;
>> rather, it signals the developer’s *intent,* thus allowing the compiler to
>> assist in making sure the developer does the right thing.
>>
>> I’d actually argue that the example above is a much, much bigger problem
>> than the objection you raised, as it can actually produce unintended
>> behavior at runtime, whereas the example with protocols can’t.
>>
>> As for the protocol example, I’d like to refine Option 3 from last night
>> slightly:
>>
>> Option 4: A keyword is required on a method declaration if and only if
>> the containing type is declared as conforming to its protocol, either in
>> its definition or in an extension that is visible within the current scope.
>>
>
> Extensions are not first-class entities and have no visibility of their
> own. In any case, you have not solved the problem, which has nothing to do
> with whether something is "reasonable to know": when a default
> implementation A is overridden by implementation B, implementation A may be
> visible only in a *more restricted* access scope than implementation B.
> (This is not the case with overriding superclass members in subclasses.) It
> can be perfectly "reasonable to know" about both A and B, but there is
> still no way you can indicate this knowledge by appending a keyword to the
> declaration for implementation B if the access scope for implementation A
> is unutterable where B is declared.
>
>
>> This allows the extension to remain empty in your example, but puts the
>> responsibility on the developer to declare conforming methods when it is
>> reasonable to know that they will satisfy a protocol.
>>
>> Charles
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160826/19ef1d55/attachment.html>