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

[Vladimir.S]

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.
>