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

[Jordan Rose]

> On May 16, 2017, at 10:44, Charles Srstka via swift-users <swift-users at swift.org> wrote:
> 
>> On May 16, 2017, at 12:32 PM, Nevin Brackett-Rozinsky via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>> 
>> There is not.
>> 
>> At some point in the future, I believe the plan is to eventually allow default implementations to be written in-line within the protocol declaration itself. In other words, the fact that default implementations currently must appear in extensions, is a temporary limitation that has not yet been a priority to address.
>> 
>> Once we gain the ability to define default implementations within protocols themselves, rather than extensions, then your use-case will “just work” (at least as long as you control the protocol anyway). I wouldn’t hold my breath though, as that behavior will not appear this year, and the plans for next year have not been hashed out yet.
> 
> Even that won’t completely solve the problem, though, because:
> 
> protocol P {
> 	func foo() {
> 		// default implementation
> 	}
> }
> 
> struct S: P {
> 	func foo() {
> 		// overriden implementation
> 	}
> }
> 
> If foo is refactored here, S will start getting the wrong implementation of it, silently, with no warning.
> 
> People have tried to bring up proposals to add some sort of “override”-like keyword for protocols on swift-evolution a bunch of times, but it always gets shouted down by certain members of the group, so we’re probably permanently stuck with this situation where a supposedly “protocol-oriented” language is not safe to use with protocols.

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

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170516/cca30b89/attachment.html>