[swift-evolution] Keyword for protocol conformance

[Charles Srstka]

> 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.

Charles

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