I was responding to Brent's mail: > Many moons ago, I was pushing to require a `final` keyword on protocol > extension methods, which would prevent conforming types from providing their > own implementations.
Where was proposed to force them to be final and was just trying to provide an example in which the conforming class may want to override them, so forcing them final isn't a good idea. Sorry about the confusion. I'm generally in favor of a modifier rather than annotation, e.g. dynamic func myFunc() nondynamic func myFunc() Dynamic now being just for vars, so perhaps extending it to functions. 21. 5. 2016 v 15:27, Matthew Johnson <[email protected]>: > > > Sent from my iPad > >> On May 21, 2016, at 8:03 AM, Charlie Monroe via swift-evolution >> <[email protected]> wrote: >> >> See the text below the quoted paragraph in my email - I've mentioned how >> extending the protocol can be helpful e.g. in case of delegate protocols - >> where you may want to extend the protocol in subclasses of the delegated >> class introducing new methods for the delegate. In such scenarios, forcing >> them final is not an option. > > Nobody is talking about forcing them final. We are talking about annotating > them with a keyword that documents their behavior (which is unintuitive for > sure but makes sense when you think through how things work behind the > scenes). > > Maybe we will figure out a way to have something better in the future, but > until then highlighting the behavior via annotation is a pretty good option. > >> >> 21. 5. 2016 v 14:25, Brent Royal-Gordon <[email protected]>: >> >>>> Making them final is not a good idea. I see the default implementations in >>>> protocols as something that should replace the optional methods in @objc >>>> protocols. >>> >>> We aren't discussing default implementations. We're discussing methods that >>> are listed *only* in the protocol extension, not in the protocol itself. >>> These methods cannot be "overridden" in the way that a defaulted protocol >>> method can be; I think it's safest to outlaw any attempt to "override" them >>> at all. >>> >>> -- >>> Brent Royal-Gordon >>> Architechies >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
