Sent from my iPad
> On May 10, 2016, at 5:46 PM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > >> On Tue, May 10, 2016 at 5:24 PM, Hooman Mehr via swift-evolution >> <[email protected]> wrote: >> >>>> On May 10, 2016, at 2:49 PM, Matthew Johnson via swift-evolution >>>> <[email protected]> wrote: >>>> That said, I’m not sure I understand the concrete use-cases. When is this >>>> concept important? When is “Self” not good enough? >>> >>> The only case where there is new functionality is when this is used in a >>> protocol requirement. I gave an example earlier today. >> >> This functionality is the key: Ability of an open (non-final) class to >> conform to a protocol that lets it return an instance of the conforming type >> (itself). Self does not work for that and we can’t change its behavior (or >> can we?) So one solution seems to be Matt’s proposal. This functionality is >> important for me and an example use case is class clusters. For the client >> code it is sealed and acts just like a final class, but internally it may >> return a subclass that is an implementation detail. We should be able to do >> this. > > Help me understand this. Maybe an example will help. Why is it a problem to > return the subclass instead of the base class? > The problem is that there is no way to guarantee that all subclasses of a non-final class provide the necessary override. See the NSURL example I posted earlier today. >> >> Hooman >> >> _______________________________________________ >> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
