[swift-evolution] Keyword for protocol conformance

[Xiaodi Wu]

On Fri, Aug 26, 2016 at 5:08 AM, Charles Srstka <cocoadev at charlessoft.com>
wrote:

> On Aug 26, 2016, at 4:34 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>
> On Fri, Aug 26, 2016 at 4:24 AM, Charles Srstka <cocoadev at charlessoft.com>
>  wrote:
>
>> On Aug 26, 2016, at 4:02 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>>
>> That is not exactly what Brent was speaking of. We are talking about this
>> scenario:
>>
>> File A:
>>
>> ```
>> internal struct S {
>>   func foo() { }
>> }
>> ```
>>
>> File B:
>>
>> ```
>> private protocol P {
>>   func foo()
>> }
>>
>> extension P {
>>   func foo() { }
>> }
>>
>> // With your proposal, I can't write the following line:
>> extension S : P { }
>> // In file A, S.foo() isn't overriding anything, so I can't add `override`
>> // But in file B, S can't conform to P,
>> // because S.foo() isn't overriding P.foo() without `override` in file A
>>
>>
>> First of all, I cannot take credit for the proposal, as the thread was
>> started by David, not me, so if the proposal is anyone’s, it’s his. With
>> that said, what he proposes is:
>>
>> On Aug 22, 2016, at 4:30 PM, David Cordero via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> *Proposal:*
>> Adding a keyword to the methods conforming protocols. As an example
>> please check the following piece of code which uses the keyword `conform`
>> to explicitly indicate that `myMethod` is a method conforming a protocol.
>>
>>
>> The wording here is that the keyword is needed for methods conforming to
>> protocols. My reading of that is that:
>>
>> File A:
>>
>> protocol P {
>> func foo()
>> }
>>
>> struct S: P {
>> conform func foo() {
>> // I am declared as conforming to P, so in adding this method I am doing
>> so to conform to P. Thus, I need the keyword.
>> }
>> }
>>
>> - - whereas: - -
>>
>> File A:
>>
>> struct S {
>> func foo() {
>> // I am not declared as conforming to any protocol; I just think that
>> being able to foo is an ability that I need to have.
>> }
>> }
>>
>> File B:
>>
>> private protocol P {
>> func foo()
>> }
>>
>> extension S: P {
>> // The area of contention.
>> }
>>
>> - - - - - -
>>
>> The proposal doesn’t really mention what to do here, so we can argue a
>> bit about it. There are multiple viewpoints one could take on this. A few
>> could be:
>>
>> 1. The extension should get some kind of keyword, “retro” or “@retro” or
>> something better-sounding that someone smarter than I comes up with.
>>
>> 2. The extension is unmarked, but declares foo() inside it with some sort
>> of annotation to indicate that it represents a method that already exists.
>>
>> 3. Just leave the extension exactly as written, since it’s not declaring
>> any methods, and thus doesn’t have to indicate what those nonexistent
>> method declarations conform to.
>>
>> I began this discussion leaning toward #1, but now I’m starting to
>> consider #3, since the purpose of the keyword is to declare one’s
>> intentions. The intentions of an empty extension that does nothing but
>> conform to a protocol is actually quite clear; the methods have to be
>> already declared somewhere else, or it makes no sense. At any rate, the
>> “problem” in your scenario is entirely confined to File B, so if any
>> annotations are necessary, that is where they belong. File A does not know
>> about the protocol, it does not know that it is conforming to the protocol,
>> and indeed, the protocol is none of File A’s business. So since File A is
>> not intending to conform to the protocol, File A does not have to declare
>> its intent to conform to the protocol. If we require that, it’s all in File
>> B’s court.
>>
>
> As I said, this discussion has already happened several times. I'm
> literally just repeating what people said eight months ago, six months ago,
> and four months ago. There's not a good answer to this and perhaps several
> other issues, which is why I don't see a way forward for the proposal.
> After all, I was the one proposing the same idea last winter, so I've had a
> few months to think about it.
>
> If option (3) were allowed, then no keyword could ever be mandatory; it's
> always possible to refactor so that a conformance declaration is an empty
> extension. So we're back at an optional keyword, which has its own
> problems. This kind of thinking is how I've come to the conclusion that the
> status quo, with better diagnostics, is the least bad solution.
>
>
> Two responses to that thought:
>
> 1) In general, I look at these things under the assumption that most
> developers are not going to be making efforts to deliberately break the
> system, and not to try to expend excessive amounts of time in preventing
> them from doing so. Because really, just about *anything* can be worked
> around. 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.
>

Really? I wasn't aware that you could work around the `override` keyword
(the one that's required for classes). How do you do that?


> For that matter, just about *everything* in Objective-C was
> workaroundable, and usually rather trivially at that, but that didn’t make
> us all go back to typing everything as ‘id’ just because the explicit types
> could be spoofed.
>

Swift, by design, is rather different from Objective-C; it makes rather
stronger guarantees about the facilities it provides. I don't know of very
many (any?) keywords that attempt to enforce safety but are optional. Are
you?

2) Even if you disagree with everything I just said, that’s just as much an
> argument for option #1 as for the status quo.
>

The status quo has the benefit of not being source breaking, and simpler.


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