Sent from my iPad
> On May 10, 2016, at 5:42 PM, Xiaodi Wu <[email protected]> wrote: > > If the use case is to support certain protocol requirements rather than > avoiding the recitation of long names, then it doesn't have to be short. IMO, > `Type` is problematic because there's nothing in the meaning of the word to > distinguish from `Self`, and in any case it's already used for the metatype > type. `StaticSelf` is unambiguous. I think both are valid uses so short is better but I agree that the distinction from Self is more readily apparent with StaticSelf. I could live with either one. > > >> On Tue, May 10, 2016 at 5:32 PM, Matthew Johnson via swift-evolution >> <[email protected]> wrote: >> >> >> Sent from my iPad >> >>> On May 10, 2016, at 5:24 PM, Hooman Mehr <[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. >> >> Agree and this is why I am willing to write the proposal for this. There >> was a discussion a few months ago about this problem and a few solutions >> were kicked around. The biggest problem with this approach at the time was >> lack of a good name, which I believe we now have in Type. >> >> I'm going to let the discussion continue for a day or two and will write a >> proposal if no significant counter arguments arise. >> >> -Matthew >> >>> >>> 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
