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