> On Apr 14, 2016, at 12:29 PM, Dave Abrahams via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
> on Wed Apr 13 2016, Joe Groff <swift-evolution@swift.org> 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
>> }
>
> This doesn't entirely work, I think:
>
> class Z : Equatable {} // ...
> class A : Z {}
> class B : Z {}
>
> let a: Equatable = A()
> let b: Equatable = B()
> if let bAsA = b as? a.Self { ... } // test fails.
>
> Of course, one could decide we don't care about classes conforming to
> protocols with Self requirements.
I don't see the problem. B is-an A, so equating an A to a B is equating an A to
an A (from the conformance's perspective, Self == A). A() == B() works by the
same principle.
>
>> 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>
>
> I don't think x.Element can work. Do you mean x.Self.Element?
TBD, when we get there, but requiring `x.Self.Element` doesn't seem necessary
to me.
-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
