[swift-evolution] Keyword for protocol conformance

[Xiaodi Wu]

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

>
> On Aug 26, 2016, at 3:19 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> Why? S.foo() is visible throughout the module, but outside this file,
>> S.foo() doesn't override anything. Why should it be marked as an `override`
>> when, as you say, the generated interface shows no sign of conformance to P?
>> In addition, how would you justify a requirement to fiddle with these
>> keywords when someone simply refactors an internally visible type with no
>> private members from one file to another? Your proposed rule just broke
>> copy-and-paste...
>>
>>
>> Because it indicates the programmer’s *intent.* If the protocol is
>> visible at the time you’re writing the declaration for S.foo(), then you
>> should have to tell the compiler what you mean by that and what you’re
>> doing with it.
>>
>
> Where a type is located in relation to a protocol is a poor proxy for
> whether one was written _before_ the other. And while the writer's most
> likely intent might differ depending on the order in which two things are
> written, how one declares members on a type should not be determined by a
> set of arbitrary rules for the compiler to guess whether the type or
> protocol was written first. This kind of functionality, if you want it,
> might be appropriate for a linter. It could probably even look at last
> modified dates, or with a git repo, go line by line to see when each piece
> of the code was written.
>
>
> Why should it matter when the programmer wrote it?
>

I don't know--that's your suggestion, not mine: "If the protocol is visible
at the time you’re writing the declaration for S.foo(), then you should
have to tell the compiler what you mean by that..."


> One is the declaration, the other is an add-on to it. Conceptually, the
> type is constructed first, and then things are bolted on (and in
> Objective-C, that’s literally what happened; I don’t know how it is
> implemented in Swift, but conceptually this is how the mental model works).
>
> Should I not have to add an “override” keyword to a subclass method simply
> because I wrote that method first and only refactored it into a superclass
> method after the fact?
>
> This seems like a fairly silly objection, IMO.
>
> I agree, it seems silly. Can you explain what you meant?

> On Aug 26, 2016, at 3:23 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> 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.
>
>
> The current syntax allows many opportunities to do the wrong thing.
>
> This is the wrong thing:
>
> protocol P {
> func foo(bar: Baz)
> }
>
> extension P {
> func foo(bar: Baz) {}
> }
>
> struct S: P {
> func foo(baz: Baz) {}
> }
>
> Refactoring this can result in another wrong thing:
>
> protocol P {
> func foo(bar: Baz, qux: Quux)
> }
>
> extension P {
> func foo(bar: Baz) {}
> }
>
> etc. etc. etc.
>
> Currently it’s hard for a linter to catch things like this, because
> there’s no way to know that I *didn’t* mean to define a similarly, but not
> exactly, named function, just as there’s no way to know that I *didn’t*
> mean to provide a simplified version of the function in the extension. And
> etc. If I could tell the compiler what I mean by those declarations,
> suddenly they it becomes possible to check them for accuracy.
>

Or, instead, you could tell a linter these things if you choose; I'm saying
your proposal of having distinct before-the-fact and after-the-fact syntax
for protocol conformance doesn't make for a good language feature, IMO.


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