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? > > 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
