[swift-evolution] [RFC] #Self

[Xiaodi Wu]

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.


On Tue, May 10, 2016 at 5:32 PM, Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> Sent from my iPad
>
> On May 10, 2016, at 5:24 PM, Hooman Mehr <hooman at mac.com> wrote:
>
>
> On May 10, 2016, at 2:49 PM, Matthew Johnson via swift-evolution <
> swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160510/97da3898/attachment.html>