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

[Ross O'Brien]

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>
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> 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>
> wrote:
>
>>
>> > Le 18 avr. 2016 à 12:01, Yogev Sitton <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
>> 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/646996f0/attachment.html>