<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Those "trampolines" are visible in debugger stack traces, or in Instruments, as "protocol witness" function calls. You may have seen them already.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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 ?).</div><div class=""><br class=""></div><div class="">I hope I was clear :-)</div><div class="">Gwendal</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">Le 18 avr. 2016 à 12:19, Ross O'Brien <<a href="mailto:narrativium+swift@gmail.com" class="">narrativium+swift@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">You may have to explain that metaphor (or link to an explanation) - what is 'trampoline' data?</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Apr 18, 2016 at 11:11 AM, Gwendal Roué <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">
> Le 18 avr. 2016 à 12:01, Yogev Sitton <<a href="mailto:yogev.sitton@gmail.com" class="">yogev.sitton@gmail.com</a>> a écrit :<br class="">
><br class="">
> I’m referring you to Ross O’Brien’s post:<br class="">
> 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.<br class="">
><br class="">
> Protocols behaves differently than closures and classes and I think they should behave the same.<br class="">
<br class="">
</span>All right, I get it.<br class="">
<br class="">
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.<br class="">
<br class="">
But maybe they will eventually, thanks to your request!<br class="">
<div class="HOEnZb"><div class="h5"><br class="">
Gwendal<br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>