> On May 16, 2017, at 12:32 PM, Nevin Brackett-Rozinsky via swift-users
> <swift-users@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.
Charles
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
