[swift-evolution] Static Dispatch Pitfalls

[Matthew Johnson]

Sent from my iPad

> On May 21, 2016, at 8:56 AM, Charlie Monroe <charlie at charliemonroe.net> 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 <matthew at anandabits.com>:
> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On May 21, 2016, at 8:03 AM, Charlie Monroe via swift-evolution <swift-evolution at swift.org> 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 <brent at architechies.com>:
>>> 
>>>>> 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
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>