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

[Yogev Sitton]

Discussion has stopped on this topic.
Should I submit a proposal?

> On Apr 18, 2016, at 1:55 PM, Ross O'Brien <narrativium+swift at gmail.com> wrote:
> 
> Thanks Gwendal, that makes sense - for the case where Shape is a protocol.
> 
> Since the OP wasn't clear about it, I tried the original example with both the cases where Shape was declared as a protocol (i.e. Circle conforms) and where Shape was declared as a class (i.e. Circle inherits). The same problem occurs when Shape is a concrete type. Does the same explanation apply? i.e. the 'MyShapeProtocol' trampoline has the same problem you've described?
> 
> Yogev: this is the first stage - discussion on the list. The formal next stage, assuming that there's some list support and the idea isn't on the list of 'commonly rejected ideas' (I've been burned by this) is to write a proposal using the draft proposal document in the Swift Evolution github repository, and make a pull request. In due course proposals will be scheduled for review. If a pull request for an implementation of an acceptable proposal exists, the review may happen that much faster.
> 
> On Mon, Apr 18, 2016 at 11:43 AM, Gwendal Roué <gwendal.roue at gmail.com <mailto:gwendal.roue at gmail.com>> wrote:
> 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 <mailto: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/20160523/cb9bde85/attachment.html>