[swift-evolution] [RFC] #Self

[Matthew Johnson]

Sent from my iPad

> On May 10, 2016, at 11:25 AM, Vladimir.S <svabox at gmail.com> wrote:
> 
> Thank you for answers, just to clarify:
> 
>> On 10.05.2016 18:47, Matthew Johnson wrote:
>> 
>>> On May 10, 2016, at 10:34 AM, Vladimir.S via swift-evolution
>>> <swift-evolution at swift.org> wrote:
>>> 
>>> What about #Self in protocols? I.e. is it proposed to have #Self in
>>> protocols, where conformance will require a substitution by real type
>>> name?
>>> 
>>> protocol A { func a() -> Self func b(c: Self) // b(c: #Self)   ? }
>> 
>> Self and #Self are different for non-final classes.  In protocol
>> requirements Self would covary and #Self would be fixed by the class
>> that provides conformance.  The distinction is pretty subtle and is
>> 
>> protocol A { func a() -> Self func b(c: #Self) }
> 
> Yes, Self and #Self sometimes is not the same, and sometimes is the same.
> Here I asked about b() method. No questions regarding a() method.
> 
> So, after #Self will be introduced, this definition will be correct:
> 
> protocol A {
>    func a() -> Self
>    func b(c: #Self)
> }
> 
> and be exactly the same as
> 
> protocol A {
>    func a() -> Self
>    func b(c: Self)
> }
> 
> Will both variants coexist? I'd prefer compiler to be strict in this case and allows only #Self in b() method, as this is more correct and explicit declaration, i.e. func b(c: Self) in protocol A really means func b(c: #Self). No?

Agree.

> 
>> 
>>> 
>>> class C: A { func a() -> Self { return self } func b(c: C) {} // b(c:
>>> #Self) ? }
>> 
>> C is non-final so we must be careful.  C and #Self both refer to the
>> same thing.  Self covaries and would thus refer to the dynamic type of
>> the instance in both signatures and bodies.  This means that a method
>> returning Self must be overridden by all subclasses in order to return
>> the correct type.
> 
> Yes, I believe it is all clear with a() method. This is why I placed the commend with #Self for `b` method only
> 
>> 
>> One of the advantages of allowing #Self in protocol requirements is that
>> it is one way to solve a problem that has receive significant discussion
>> on the list in the past: retroactively conforming non-final classes to
>> protocols with factory methods that do not need to covary.  There is no
>> way to express a this kind of requirement in the language today.
>> 
> 
> Could you please illustrate this in a couple lines of code? Just to fully understand.

protocol A {
  static func createWithString(s: String) -> Self
}

extension NSURL: A {
  // cannot conform because NSURL is non-final
}

If we could define a protocol requirement that didn't covary (using #Self or whatever) we would be able to write the desired conformance.

> 
>>> 
>>> 
>>> protocol A2 { var a: Self {get} }
>>> 
>>> final class C2 : A2 { var a: C2 { return C2() } // #Self { return
>>> #Self() }  ? }
>> 
>> In final classes and value types the type name itself (C2 in this
>> example), Self, and #Self would all reference the same thing.
>> 
> 
> Exactly in my example, you can't use `Self` keyword in class:
> 
> final class C2 : A2 {
>    var a: Self { return Self() } // error
> }
> 
> but I expect to be able to have:
> 
> final class C2 : A2 {
>    var a: #Self { return #Self() }
> }
> 
>>> 
>>>> On 10.05.2016 17:50, Erica Sadun via swift-evolution wrote:
>>>> As a compile-time substitution, it could be used in any and all of
>>>> the examples in your bullet list as a literal text replacement..
>>>> 
>>>> Quick rundown:
>>>> 
>>>> struct A { ...#Self... // #Self is substituted by A }
>>>> 
>>>> class B { ...#Self... // Self is substituted by B }
>>>> 
>>>> class C { ... #Self... // Self is substituted by C, which is the
>>>> defining type at compile time }
>>>> 
>>>> I'm stepping away from endorsing or pushing this forward. If you
>>>> want to pick this up and run with it, it's yours.
>>>> 
>>>> -- E
>>>> 
>>>> 
>>>>> On May 10, 2016, at 8:34 AM, Matthew Johnson
>>>>> <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>>>>> 
>>>>> Can you clarify where would #Self would be allowed?
>>>>> 
>>>>> * property declarations * method signatures * method and computed
>>>>> property bodies * all of the above
>>>>> 
>>>>> I would like to see this and allowed in all of the above.
>>>>> 
>>>>> We should also consider allowing this in protocol requirements.
>>>>> It would not covary like Self does for return types, instead being
>>>>> fixed by the class that declares conformance.
>>>>> 
>>>>> Sent from my iPad
>>>>> 
>>>>> On May 10, 2016, at 8:15 AM, Erica Sadun via swift-evolution
>>>>> <swift-evolution at swift.org <mailto:sw