That’s was my point. Two sets of rules for the same case in two different places. These should be unified.
I’ll write the proposal and create a pull request. On Aug 17, 2016, at 11:24 PM, Slava Pestov <[email protected]<mailto:[email protected]>> wrote: On Aug 17, 2016, at 10:18 AM, Vladimir.S via swift-evolution <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected]<mailto:[email protected]> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
