[swift-evolution] Keyword for protocol conformance

[Charles Srstka]

> 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 <mailto:cocoadev at charlessoft.com>> wrote:
>> On Aug 26, 2016, at 2:38 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>> 
>> On Fri, Aug 26, 2016 at 2:34 PM, Charles Srstka <cocoadev at charlessoft.com <mailto:cocoadev at charlessoft.com>> wrote:
>>> On Aug 26, 2016, at 2:29 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto: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.

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.

Charles

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