[swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

[Ilya Belenkiy]

+1. Completely agree with what Eugene said.
On Thu, Apr 14, 2016 at 1:14 AM Eugene Gubin via swift-evolution <
swift-evolution at swift.org> wrote:

> I like this idea. I think, if we could use `self` to access instance of
> self, we should be allowed to use `Self` to access type of self.
>
> 2016-04-14 8:46 GMT+04:00 William Dillon via swift-evolution <
> swift-evolution at swift.org>:
>
>> This would be great!
>>
>> I use a nearly identical pattern in my networking framework that would be
>> nice to streamline:
>>
>> public func ==(lhs: NetworkAddress, rhs: NetworkAddress) -> Bool {
>>     // Only addresses of the same protocol are considered equal.
>>     guard lhs.dynamicType == rhs.dynamicType else {
>>         return false
>>     }
>>
>>
>>     if lhs.dynamicType == IPv4NetworkAddress.self {
>>         return (lhs as! IPv4NetworkAddress) == (rhs as!
>> IPv4NetworkAddress)
>>     }
>>
>>     if lhs.dynamicType == IPv6NetworkAddress.self {
>>         return (lhs as! IPv6NetworkAddress) == (rhs as!
>> IPv6NetworkAddress)
>>     }
>>
>>
>>     return false
>> }
>>
>> - Will
>>
>> On Apr 13, 2016, at 6:41 PM, Joe Groff via swift-evolution <
>> swift-evolution at 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
>> }
>>
>> 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 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
>>
>>
> _______________________________________________
> 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/20160414/74a9f784/attachment.html>