Sorry Brent, I obviously didn’t read down to the alternatives section. Stupid me.
I think that it is a larger change, but if we’re going to change this, shouldn’t we do it right? From my perspective, a protocol says what “should” happen, whereas a type is where it eventually “does” happen. I find it a little backwards to make protocol extensions mandatorily final. It blocks out the power of defaulting. I definitely agree with you that final in protocol extensions is a great idea, though. > On 5 Jan 2016, at 10:13 AM, Brent Royal-Gordon <[email protected]> wrote: > >> The question then becomes simple: should a type gave the right to replace >> the value in the protocol? Should protocol extensions therefore only be >> defaults? >> >> I would argue for treating the protocol as a default. If you had an >> identical member in the type, use the type rather than the protocol >> extension. This allows the most flexibility. That said, I am aware that >> means that some optimisations are not possible. I simply think this makes >> the most sense from a programming perspective. > > I discuss this in the Alternatives section: > >> ### Dynamically dispatch calls to protocol extension members >> >> This would fix the underlying problem—the confusing behavior—by making >> protocol extension members not behave confusingly. >> >> This would likely take a redesign of protocol witnesses to include extension >> methods not listed in the original protocol. It's probably not >> impossible—class extensions behave this way—but it's a much bigger change >> than what I propose, which keeps the current runtime semantics and only adds >> compile-time errors and keywords. >> >> Dynamically dispatching to protocol extension members would also change the >> performance characteristics of these calls. Even if this change were made, >> we might want to allow users to apply `final` to extension methods which >> they want to be dispatched statically. > > Basically, I'm not proposing that simply because it's a larger change and > would take redesigning that would have to wait until at least Swift 3, and is > well beyond my own ability to specify or even evaluate the feasibility of. > Plus, as I said in that last paragraph, `final` protocol extension members > may be useful even if we do treat extension members as equivalent to > defaulted protocol members. > > -- > Brent Royal-Gordon > Architechies > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
