[swift-evolution] PITCH: Return a subclass for a protocol method without the need for an associatedtype

[Slava Pestov]

> On Aug 17, 2016, at 10:18 AM, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:

> But yes, strictly speaking 'make()->Circle?' conforms to protocol requirement 'make()->Shape?', it does returns 'Shape?', so I believe this should be treated as conformance to MyShapeProtocol protocol.

I agree this should be made to work, especially since method overriding supports the exact same scenario.

We have two sets of rules, implemented in two different places, for matching method overrides and protocol witnesses. We need to unify the rules and the code.

Slava

> 
> 
> On 17.08.2016 10:09, Sitton, Yogev via swift-evolution wrote:
>> Hi,
>> 
>> I raised this issue a few months back and discussion has died out since.
>> I’m raising this again to see if there are any objections before I submit a
>> proposal.
>> 
>> 
>> 
>> I have a class that conforms to a protocol which declares a method with a
>> specific return type.
>> In case I want to return a subclass of the return type I am forced to use
>> anassociatedtype.
>> This feels like a hack.
>> 
>> *Example:*
>> 
>> // The protocol
>> protocol MyShapeProtocol {
>> // returns Shape
>> func make() -> Shape?
>> }
>> 
>> // Circle inherits from Shape
>> class Circle : Shape {}
>> 
>> // CircleMaker conforms to the MyShapeProtocol
>> class CircleMaker : MyShapeProtocol {
>> // CircleMaker wants to return Circle which is a type of Shape
>> func make() ->Circle? {
>> return Circle()
>> }
>> }
>> 
>> This will not work.
>> For that to work I’ll need to use toe associatedtype “hack”:
>> 
>> *Example:*
>> protocol MyShapeProtocol {
>> associatedtype ShapeReturnType : Shape
>> func make() -> ShapeReturnType?
>> }
>> 
>> class Circle : Shape {}
>> 
>> class CircleMaker : MyShapeProtocol{
>> func make() ->Circle? {
>> return Circle()
>> }
>> }
>> 
>> What I’m suggesting is to allow to return a subclass for a protocol method
>> without the need for an associatedtype.
>> 
>> Any reason why not?
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution