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

Ross O'Brien narrativium+swift at gmail.com
Mon Apr 18 05:19:33 CDT 2016


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/1a1a9ecd/attachment.html>


More information about the swift-evolution mailing list