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
}
> On 11 May 2016, at 8:32 AM, Matthew Johnson via swift-evolution
> <[email protected]> wrote:
>
>
>
> Sent from my iPad
>
> On May 10, 2016, at 5:24 PM, Hooman Mehr <[email protected]
> <mailto:[email protected]>> wrote:
>
>>
>>> On May 10, 2016, at 2:49 PM, Matthew Johnson via swift-evolution
>>> <[email protected] <mailto:[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
