[swift-evolution] Bridging the gap between protocols and protocol extensions

[Howard Lovatt]

I have put a proposal in for generic protocols and covariant generics:

	[swift-evolution] Make generics covariant and add generics to	protocols  <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006367.html>  <>

This proposal requires that protocol functions are dynamically dispatched, i.e. it would require this change.


> On 11 Jan 2016, at 12:34 PM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Jan 10, 2016, at 5:21 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
>>> If we make protocol extension methods dynamically dispatched (even as just an opt-in thing), we’d probably use a caching technique akin to objc_msgSend, keyed by the address of some global structure unique to the extension method.  This has the huge advantage of not requiring eager resolution of every extension method on every conformance, and it can still be made very fast — on the order of a few dozen cycles, i.e. maybe 50-75% slower than a v-table dispatch.  So it will not be as fast as a core requirement, but it’s likely to be close enough that all but the most performance-conscious programmers will be unaware of the difference, in the same way that most Java programmers have no need to be aware that dispatch through an interface type is usually slower than dispatch through a class type.
>> 
>> Thanks, John. So if I'm reading this right:
>> 
>> 1. It is a significant engineering effort (you can't just rearrange things in the existing vtables), but definitely doable.
>> 
>> 2. It would have reasonably good performance, but performance-sensitive code might want a statically-dispatched alternative.
>> 
>> Is that an accurate reading? Is it reasonable to propose for Swift 3, or would it require too much work for that timeframe?
> 
> It’s something we need to figure out before committing permanently to an ABI, and that makes it a logical part of the Swift 3 effort to at least leave room for this.
> 
> John.
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160112/6f2168f8/attachment.html>