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

[Vladimir.S]

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) {   }
}

but

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

   func f() {
     DynamicSelf.someStaticMethod()
   }
}


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