-1 from me. To me this is not *obvious* as to what "Self" it means.
And it seems possible to run into this:
self.someClass.Self
Just looks confusing to me. What's wrong with using "Type" or something more
obvious?
Sent from my iPad
> On Apr 14, 2016, at 10:28 AM, Vladimir.S via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> +1, I also support. We already have Self in meaning of dynamicType as result
> of method, for example:
>
> class A {
> func some()->Self {
> //print(self.dynamicType) // btw: if we uncomment this - will get
> run-time error wtf??
> return self
> }
> }
>
> class B:A {
> }
>
> var aa = B()
>
> print(aa.some().dynamicType)
>
> so why do we need to have this "dynamicType" instead of "Self".
> It seems to be natural to have
>
> print(aa.some().Self)
>
>
>> On 14.04.2016 4:41, Joe Groff via swift-evolution wrote:
>> It's been pitched before, but I don't think we've had a dedicated thread to
>> this idea. Erica has proposed making `Self` generally available within
>> methods in types to refer to the dynamic type of the current receiver. One
>> could think of `Self` as a special associated type member that exists in
>> every type for this purpose. This also happens to be what you get when ask
>> for the `dynamicType` member of a value. We could unify these concepts and
>> get rid of the clunky `dynamicType` keyword, replacing it with `x.Self`.
>>
>> There's another benefit to this syntax change. Looking to the future, one of
>> the many features Doug pitched in his generics manifesto was to generalize
>> protocol existentials, lifting our current restrictions on protocols "with
>> Self or associated types" and allowing them to be used as dynamic types in
>> addition to static generic constraints. Once you do this, you often want to
>> "open" the type of the existential, so that you can refer to its Self and
>> associated types in the types of other values. I think a natural way would
>> be to let you directly use Self and associated type members of existentials
>> as types themselves, for example:
>>
>> let a: Equatable = /*...*/
>> let b: Equatable = /*...*/
>>
>> // This is not allowed, since Equatable requires two values with the same
>> static type, but
>> // a and b may have different dynamic types.
>> a == b
>>
>> // However, we can dynamically cast one to the other's dynamic type:
>> if let bAsA = b as? a.Self {
>> return a == bAsA
>> }
>>
>> let x: RangeReplaceableCollection = /*...*/
>> let y: Collection = /*...*/
>>
>> // If y has the same dynamic Element type as x, append it to x
>> var z: x.Self = x
>> if let yAsX = y as? Any<Collection where Element == x.Element> {
>> z.append(yAsX)
>> }
>>
>> `x.Self` then becomes just the first step in this direction.
>>
>> -Joe
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
