[swift-evolution] [swift-evolution-announce] [Review] SE-0068: Expanding Swift Self to class members and value types

[Vladimir.S]

On 25.04.2016 20:18, Michael Peternell via swift-evolution wrote:
> Is "Self" dynamically dispatched? What would the following program print?

In your example you can just replace "Self" to "self.dynamicType", the more 
questions appear if "Self" is used in protocol as result type and as 
parameter type

>
> class A: NSObject {
>     static func myClassName() -> String {
>         return "A"
>     }
>     func hello() -> String {
>         return "I am a \(Self.myClassName())"
>     }
> }
>
> class B: A {
>     static func myClassName() -> String {
>         return "B"
>     }
> }
>
> print(B.init().hello())
>
> Because I think "Self" would only cause confusion if it is statically dispatched. assert(B.init().hello() == "I am a B")
>
> -Michael
>
>> Am 25.04.2016 um 13:33 schrieb Vladimir.S via swift-evolution <swift-evolution at swift.org>:
>>
>> On 25.04.2016 4:57, Brent Royal-Gordon via swift-evolution wrote:
>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md
>>>
>>> I'm not totally clear what's being proposed here.
>>>
>>> Is this valid?
>>> ...
>>
>> Yes, I'm also confused if it is a final proposal or some additions/changes are expected here? As we were also discussing #Self (in meaning "placeholder for name of current defining type", resolving at compilation time)
>>
>> Also, there were notes regarding this proposal by @Alex Martini<amartini at apple.com> 21.04.2016 18:58 (quoted below), with suggestion for "dynamictype" keyword / "dynamicType" standard library function.
>>
>> @Brent, your questions could be(in general) answered by replacing "Self" to "dynamicType", but actually there are more questions on this proposal, which I suggest to discuss.
>>
>> We have some mess *right now* with all these dynamicType/self/Self :
>>
>> * "self" in meaning of current instance reference (OK), dynamicType is dynamic type of the instance :
>> class A { func f() { self.something() } }
>> self.dynamicType is A
>>
>> * "self" in meaning of current type object in static/class methods, dynamicType is meta type
>> class A { static func f() { self.something() } }
>> self.dynamicType is A.Type
>>
>> * "Self" in meaning "placeholder to concrete defining class name" :
>> protocol AProtocol {  func assignFrom(a: Self)  }
>> class A : AProtocol {  func assignFrom(a: A) {..}  } // "A" here,not "Self"
>>
>> * "Self" in meaning of dynamic type in runtime:
>> class A {  func f() -> Self { return self }  }
>>
>>
>> I'd like to discuss how the following current code should looks in Swift 3.0 :
>>
>> ----------------------------
>> protocol Proto {
>>    func z() -> Self
>>    func z(s: Self) // I propose the #Self here
>> }
>>
>> class X: Proto {
>>    required init () {}
>>    func x() -> Self { return self.dynamicType.init() }
>>    func z() -> Self { return self }
>>    func z(s: X) {} // propose z(s: #Self) here
>>
>>    static func staticF() -> Self {..} // shouldn't be #Self here?
>>    class func classF() -> Self {..}
>> }
>> ----------------------------
>>
>>
>>
>> "Notes from Swift core team 2016-04-20 design discussion" :
>>
>> On 21.04.2016 18:58, Alex Martini via swift-evolution wrote:
>>>
>>>      SE-0068: Expanding Swift Self to class members and value types
>>>
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md
>>>
>>> We have one keyword left in the language, dynamicType, which is camel
>>> cased. This proposal renames it to Self instead.
>>>
>>> In a static function today, self.dynamicType will give you a metatype but
>>> the non-member Self will not. The most useful reason to reference it is to
>>> call an initializer. It makes accessing the metatype weirder. It’s
>>> not Self.Type; that’s a type — you have to spell it Self.type.
>>>
>>> Quiz time! What do each of the permutations mean?
>>>
>>> Self.self
>>> self.Self
>>> Self.Self
>>> self.self
>>>
>>> The number of capital letters gives you the level of meta-ness. This is
>>> very subtle, which is probably not a good thing.
>>>
>>> Another approach would be to introduce a new dynamictype keyword that
>>> doesn’t need to be accessed as a member of self, and keep Self the way it
>>> is.  Self should work in structs as a type alias.
>>>
>>> Why don’t we turn this into a standard library function? It’s not something
>>> you need so often that the member access is very valuable. Putting it in
>>> the standard library as dynamicType(_:) does still allow for that function
>>> to be implemented using compiler magic.
>>>
>>> func dynamicType<T>(_: T) -> T.Type { }
>>>
>>> We have a proposal to remove .self on types. One reason .self exists is to
>>> avoid the mistake of writing let x = Int — the compiler will give you a
>>> weird type error later on in code if the value of x is what we today
>>> call Int.self but you meant to call the Int() initializer. Creating a
>>> metatype is not a common operation, so doing it explicitly is a good thing.
>>>
>>> It’s weird that you can use the metatype directly to construct something or
>>> to do member access, but you can’t access it as a bare value.
>>>
>>> Coming back to this proposal, if we removed .self why would we want to
>>> add .Self?
>>>
>>> If you have a variable whose value is a metatype, you also keep its name in
>>> lower case. So Self makes a little less sense from that aspect too.
>>>
>>> Another perspective is that .dynamicType is just an implicitly synthesized
>>> property on all type.
>>>
>>> We do have other keywords that follow the dot on
>>> types, Int.Type and Fooable.Protocol, so this isn’t the only thing. Those
>>> things are magic nested types.
>>>
>>> Subjectively, having dynamicType as a member feels weird.
>>>
>>> If .self goes away, the four-self example above is simplified,
>>> and .Self doesn’t make sense anymore. There’s also the difference
>>> that .Self would be a runtime thing.
>>>
>> _______________________________________________
>> 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
>