[swift-evolution] Keyword for protocol conformance

[Charles Srstka]

> 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 <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: the keywords, if properly designed, can allow all parties to be clear as to what they mean and catch any mistakes involved in doing so, which is all we need here. Once compiled, everything will behave identically to how it behaves today.

Charles

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