Sent from my iPad
> On May 21, 2016, at 8:56 AM, Charlie Monroe <[email protected]> wrote: > > 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. Again, nobody ever proposed forcing them final. The proposal was to use final as a way to document the existing behavior. You and many others are asking for a new option of dynamic dispatch of protocol extensions. We may see this someday but it is not going to happen in Swift 3. > 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. By annotation I just meant something indicating behavior. Your 'nondynamic' qualifies, but is not the right term. 'dynamic' in Swift does not just mean dynamic dispatch semantics. It means always dispatched through the Objective-C runtime. If it didn't already have this meaning I would probably like 'nondynamic' quite a bit as a more precise alternative. > > 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
