[swift-evolution] Keyword for protocol conformance

[Xiaodi Wu]

On Fri, Aug 26, 2016 at 3:09 PM, Charles Srstka <cocoadev at charlessoft.com>
wrote:

> On Aug 26, 2016, at 2:58 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>
> On Fri, Aug 26, 2016 at 2:48 PM, Charles Srstka <cocoadev at charlessoft.com>
>  wrote:
>
>> On Aug 26, 2016, at 2:38 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>>
>> On Fri, Aug 26, 2016 at 2:34 PM, Charles Srstka <cocoadev at charlessoft.com
>> > wrote:
>>
>>> On Aug 26, 2016, at 2:29 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>
>>>
>>> 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?
>>>
>>>
>>> It is an example of an override occurring without the “override”
>>> keyword, and a demonstration that the “override” keyword’s purpose is to
>>> indicate programmer intent rather than do anything to the actual generated
>>> machine code (otherwise, the override here wouldn’t have happened). Despite
>>> this, no one argues against the existence of the “override” keyword.
>>>
>>
>> This is not an example of that at all. You can't get the Swift compiler
>> to compile the code. Failure to use `override` is a compile-time error, and
>> compile-time errors don't happen at runtime. Why are we talking about
>> 'generated machine code'?
>>
>>
>> Exactly; compile-time errors are intended to enforce correct behavior on
>> the part of the developer. Your objection, as I understand it, is that a
>> type that declares a method, which another file retroactively conforms to a
>> private protocol that the original type can’t see, can’t indicate
>> conformance in its original declaration, and that this would, in some way,
>> cause a practical problem. I am failing to see what the problem is:
>>
>
> We were discussing your option (3), which would mean that trivial
> refactoring would lead to a lack of compile-time errors even if no one ever
> used your proposed keyword, effectively making the keyword optional. You
> wrote: 'I can work around the “override” keyword and override things
> without it, but that doesn’t mean that I think we should remove the
> “override” keyword.' This was surprising to me, because if it were possible
> to avoid using `override` without a compile-time error, I would indeed
> argue that we should remove the `override` keyword. However, you gave an
> example where *not compiling* means you don't get a *compile-time error*,
> which is not a workaround at all.
>
>
> We were talking about retroactive modeling, and the effects that adding
> things after the fact can have on previously-existing code. This was, I
> think, a pretty close analogue for classes. The original app compiles, the
> library compiles, the refactored library compiles.
>

We were talking about language design and rules to be enforced at compile
time; there is simply no analog here because your example was about the
runtime behavior of apps that call into libraries.

If you want it all to compile at the same time, well, we’ve still got
> access to all the Objective-C runtime functions in Swift. One can also
> write the assembly by hand. Things like “override” aren’t security
> features; they’re there to help you do the right thing. If you’re
> deliberately trying to do the wrong thing, I don’t think that can strictly
> be prevented.
>

The current syntax is not the "wrong thing"--and a future language feature
shouldn't leave a loophole where someone can choose either one or another
totally different set of rules for conforming a type to a protocol; there
should be one syntax for doing that in Swift.


>
> Charles
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160826/4f97195b/attachment.html>