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

Vladimir.S svabox at gmail.com
Thu Apr 21 02:20:07 CDT 2016

I feel like we should separate all these self/Self/dynamicType explicity.

For example :

DynamicSelf - where we use "self.dynamicType" in instance methods and 
"self" in class/static methods

#ThisType (or #Type or #Self or ?) - where we need a replacement for "the 
exactly type name where this method is declared"

I.e. you'll have
   struct SomeType {
     func f(x: #ThisType) {}

protocol SomeProtocol {
   func f(x: #ThisType)

class SomeClass: SomeProtocol {
   func f(x: #ThisType) {   }


class SomeClass {
   class func classF() { DynamicSelf.someOtherClassF() }

   func f() {

On 20.04.2016 21:37, Dave Abrahams via swift-evolution wrote:
> on Wed Apr 20 2016, Chris Lattner <swift-evolution at swift.org> wrote:
>> Hello Swift community,
>> The review of "SE-0068: Expanding Swift Self to class members and value types"
>> begins now and runs through April 25. The proposal is available here:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md
> Caveat: somewhat scattered response, probably after insufficient
> review; apply salt liberally.
> This looks like a good idea overall to me, but I think it may leave
> important uses for Self on the floor.  For example, I still want to
> write this:
>   struct SomeType {
>     func f(x: Self) {}
>   }
> Does the proposal make that work in some way that I've overlooked?
> IMO it's a shame that you can't take a protocol body, dump it into your
> type's body, and fill in the implementations to satisfy a conformance
> without finding all the instances of “Self” and replacing them with your
> type's name, and it would be sad if this proposal didn't address that
> somehow.  In general, I'm concerned that we may be making “Self” mean
> two very different things in different contexts: IIUC one is a type
> that's fully-resolved at compile time, and the other one is a value that
> holds a metatype.  If there were less of a wall between the two
> uses/contexts, that would make the proposal more palatable to me.

More information about the swift-evolution mailing list