[swift-evolution] [RFC] #Self

[Xiaodi Wu]

On Tue, May 10, 2016 at 8:45 PM, Patrick Smith via swift-evolution <
swift-evolution at swift.org> wrote:

> I think Type fits really well. Because every class, struct, and enum gets
> a static member called ‘Type’. But you can only use it outside the
> declaration (String.Type), not inside.
>
> So similar to how types declared inside can be referenced:
>
> struct A {
>   enum Kind {
>     case cat
>     case dog
>   }
>
>   var kind: Kind // Use nested type here; I don’t have to write A.Kind
> }
>
>
> We could use Type in a similar way:
>
> struct B {
>   // This gets created automatically for every type, and is accessible
> today from B.Type
>   //metatype Type { … }
>
>   var children: [Type] // Use here in the same way as Kind above
> }
>

That's neat! My issue with it is that the analysis breaks down with
protocols. If we extend it there, it's difficult to rationalize why Type
has to mean the static type of the conforming class and Self has to mean
the dynamic type.


>
>
> On 11 May 2016, at 8:32 AM, 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
>
>
>
> _______________________________________________
> 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/3a8a39dd/attachment.html>