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

[Yogev Sitton]

Hi Gwendal,

I’m actually trying to start a discussion that will change the current behavior of the language.
That’s why I posted this on the swift-evolution mailing list and not swift-users.

Yogev

> On Apr 18, 2016, at 12:48 PM, Gwendal Roué <gwendal.roue at gmail.com> wrote:
> 
> Hello Yogev,
> 
> I think your question belongs to the swift-users mailing list (quoting https://lists.swift.org/mailman/listinfo):
> 
> - swift-evolution: Discussion of the evolution of Swift, including new language features and new APIs.
> - swift-users: For users to get help with or ask questions about Swift or its related tools
> 
> Gwendal Roué
> 
>> Le 17 avr. 2016 à 10:52, Yogev Sitton via swift-evolution <swift-evolution at swift.org> a écrit :
>> 
>> I have a class that is conforming to a protocol with a method that requires a specific return type.
>> In case I want to return a subclass of the return type I am forced to use an associatedtype that feels like a hack.
>> 
>> As an example:
>> 
>> protocol MyShapeProtocol {
>>    func make() -> Shape?
>> }
>> 
>> class Circle : Shape {}
>> 
>> class CircleMaker : MyShapeProtocol{
>>    func make() -> Circle? {
>>        return Circle()
>>    }
>> }
>> 
>> This will not work.
>> For that to work I’ll need to use toe associatedtype “hack”:
>> 
>> protocol MyShapeProtocol {
>>    associatedtype ShapeReturnType : Shape
>>    func make() -> ShapeReturnType?
>> }
>> 
>> class Circle : Shape {}
>> 
>> class CircleMaker : MyShapeProtocol{
>>    func make() -> Circle? {
>>        return Circle()
>>    }
>> }
>> 
>> Is there a real value in adding the associatedtype line?
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>