<html><body><div>Am 07. April 2016 um 14:17 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org>:<br></div><div><br><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><blockquote type="cite" class="quoted-plain-text">As I understand it, the proposal is that `Self` can be used as an alias to `self.dynamicType`, which is an object in the sense of entity in Swift but not an instance of a class or struct.</blockquote><br>You don't understand it correctly.<br><br>Currently, `Self` in a class definition means "whatever subclass this object happens to be". So if you say this:<br><br> class Parent {<br> func foo() -> Self<br> }<br> class Child: Parent {}<br><br>Then on `Child`, the `foo()` function returns `Self`.<br><br>`Self` isn't supported in value types because, since you can't subclass value types, it always means exactly the same thing as writing the type's name. `Self` also isn't supported in the bodies of class members because, when you call members on it, it's equivalent to `self.dynamicType`. This is actually really strange, though, because it means that you can't actually write certain types explicitly. For instance:<br><br> class Foo { <br> func foo() -> Self { <br> let new = self.dynamicType.init()<br> // `new` is of type Self, but you can't actually write `let new: Self`<br> return new <br> } <br> required init() {} <br> } <br><br>What this proposal is saying is:<br><br>* `Self` will be allowed in value types. It will always mean the same thing as writing the type's name explicitly, but that's okay; it's more readable.<br>* `Self` will be allowed in member bodies. This will allow you to write that `new` line as:<br><br> let new: Self = Self()<br><br>Oh, and `#Self` will also be permitted, which is always literally just a shorthand for whatever type you happen to be in right now.<br><br><blockquote type="cite" class="quoted-plain-text">My point, though is not the exact semantics of what you call the thing that `Self` is but that having it and `self` in the same code will lead to readability issues because you can have `self` and `Self` in the same code referring to completely different things and they only differ in the case of the first letter.</blockquote><br>People seem to be okay with things like `var string: String`; having `self` be of type `Self` is no different.<br><br>* * *</span></div></div></blockquote></div><div><span><br data-mce-bogus="1"></span></div><div><span>Sounds all good to me!</span></div><div><span><br data-mce-bogus="1"></span></div><div><span> <br></span><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content">Having said all this, now that we have `#Self`, I'm wondering if we still want `Self` in value types. The two are *exactly* equivalent in value types as far as I can tell, and `Self` in classes implies dynamic behavior which is not supported by value types. The use of `Self` in class member bodies is a clean win, the existence of `#Self` is a clean win, but I'm not sure we need the value type thing too.</span></div></div></blockquote></div><div><span><br data-mce-bogus="1"></span></div><div><span>If subtyping for value types will be introduced someday (there has been considerable interest for that already) `Self` would make sense for value types, too, wouldn't it?</span></div><div><span><br data-mce-bogus="1"></span></div><div><span>-Thorsten</span></div></div></body></html>