[swift-users] override-like keyword for default implementations

[Charles Srstka]

> On May 16, 2017, at 4:41 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> I object to this characterization. People have tried to bring up such proposals, and it is invariably pointed out (usually by the same group of us) that these proposals don't discuss retroactive modeling, and then the thread dies. I can't remember a case where the proposal author actually incorporates this feedback into their proposal to handle retroactive modeling, or extension members of one protocol being used as the default implementation of another protocol.
> 
> (This just means the problem space is more difficult than the proposer initially thought, and they're not going to take that on right now, which is fine. It's a learning experience; designing features that interact well with the whole language is not easy! We should probably add this to the "commonly proposed" list, though, so that we don't keep retreading that initial ground.)

There have been a number of suggestions made on the list; many involve the idea of spelling retroactive conformances differently from non-retroactive ones somehow, since the two look exactly the same but really aren’t doing the same thing. Off the top of my head, I remember seeing suggestions for a “retroactive” keyword, suggestions to include the method signatures without bodies, various mapping syntaxes, etc. They don’t ever seem to get much attention or traction.

The reason it’s frustrating to me is that I spent a lot of time last year dealing with a refactor where I kept finding ‘stragglers’ at runtime, post-refactor, a situation that wouldn’t have happened if I’d used classes and inheritance. Also frustrating is the fact that it’s probably all off the table now, since any change made at this point would certainly be source-breaking.

> On May 16, 2017, at 5:05 PM, Slava Pestov via swift-users <swift-users at swift.org> wrote:
> 
> It’s not clear if such a keyword can be designed in a way that covers all cases. For example, consider a protocol extension that provides a default implementation for a requirement in a different protocol:
> 
> protocol R {
>  func f()
> }
> 
> protocol P {}
> 
> extension P {
>  func f()
> }
> 
> struct S : R, P {}

Huh, I didn’t know that that would work. I’d figured that since methods in protocol extensions that aren’t in the protocol are strictly statically dispatched, they wouldn’t participate in protocol method lookup.

Anyway, my ideal would probably be to broaden the concept a bit, since most of the issue comes from the problem of knowing whether a protocol has a default implementation or not. I’d prefer to require a keyword for *all* protocol implementations:

protocol P {
	func foo()
}

struct S: P {
	implement func foo() { … } // doesn’t matter whether some extension provides foo() or not
}

I think that would take care of the issue with the constrained extension. As for retroactive, I’m pretty agnostic about how that’s handled, but I’ve seen:

protocol P {
	func foo()
}

struct S {
	func foo()
}

retroactive extension S: P {}

or:

extension S: P {
	implement func foo() // with no body
}

I remember seeing some as well that actually allowed the struct’s method to be named something other than “foo”, with a way to map “foo” to the actual method name, but I can’t remember what syntax they used.

Charles