[swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype

[Gwendal Roué]

Those "trampolines" are visible in debugger stack traces, or in Instruments, as "protocol witness" function calls. You may have seen them already.

You see, a variable of type SomeProtocol, or the result of a method that returns a protocol, does not contain a value of any concrete type that adopts the protocol.

Instead, it contains a description of what should happen when a protocol method is called. It's an indirection. An indirection that happens at runtime. The compiler says: "I have to store a value of type T in a variable declared as protocol P. I'll actually store the fact that when the function f() of the protocol is called, it will actually call the function f() of the type T." And those redirections are visible as "protocol witness" in our stack traces.

This allows a function that uses a Swift protocols to be used with types that are not known yet by the compiler, such as the types defined by the user that use a framework. Compile once, and run later, through the indirection.

This also explains why it's not trivial to implement Yogev's request: a value of type Circle (concrete type) has not the same memory layout than a value of type Shape (a protocol trampoline). The same for functions that involve those types. Some conversion has to happen, and this conversion must happen at runtime, as we've seen above. Such support is not implemented (yet ?).

I hope I was clear :-)
Gwendal


> Le 18 avr. 2016 à 12:19, Ross O'Brien <narrativium+swift at gmail.com> a écrit :
> 
> You may have to explain that metaphor (or link to an explanation) - what is 'trampoline' data?
> 
> On Mon, Apr 18, 2016 at 11:11 AM, Gwendal Roué <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> > Le 18 avr. 2016 à 12:01, Yogev Sitton <yogev.sitton at gmail.com <mailto:yogev.sitton at gmail.com>> a écrit :
> >
> > I’m referring you to Ross O’Brien’s post:
> > As of Swift 2.2, if a variable has a closure type of e.g. () -> Shape, a closure of type () -> Circle would be considered a match.  If a class implements 'func make() -> Shape', a subclass implementing 'func make() -> Circle' has to override. However, if a protocol requires a 'func make() -> Shape', a type implementing 'func make() -> Circle' isn't considered to be conforming. That does seem strange.
> >
> > Protocols behaves differently than closures and classes and I think they should behave the same.
> 
> All right, I get it.
> 
> Shape, as a return type, is "trampoline" data that wraps any Shape value, when Circle is just a Circle. That's why the two functions () -> Shape? and () -> Circle? don't match today.
> 
> But maybe they will eventually, thanks to your request!
> 
> Gwendal
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 

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