[swift-evolution] Keyword for protocol conformance
xiaodi.wu at gmail.com
Fri Aug 26 14:58:12 CDT 2016
On Fri, Aug 26, 2016 at 2:48 PM, Charles Srstka <cocoadev at charlessoft.com>
> 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>
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution