[swift-evolution] Keyword for protocol conformance

[Xiaodi Wu]

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.


> 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/717dc657/attachment.html>