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.
On Mon, Apr 18, 2016 at 12:55 AM, Yogev Sitton via swift-evolution < [email protected]> wrote: > In what way? > > > > > > On Sun, Apr 17, 2016 at 3:53 PM -0700, "Howard Lovatt" < > [email protected]> wrote: > > I think this should be part of completing generics. >> >> On Sunday, 17 April 2016, Yogev Sitton via swift-evolution < >> [email protected]> wrote: >> >>> 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? >>> >> >> >> -- >> -- Howard. >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
