[swift-evolution] [RFC] #Self

[Vladimir.S]

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?

>
>>
>> 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 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:swift-evolution at swift.org>>
>>>> wrote:
>>>>
>>>>> To focus SE-0068 and narrow its scope, I removed the `#Self`
>>>>> part of the proposal. This offered compile-time substitution of
>>>>> the defining type for a related #Self literal:
>>>>>
>>>>> A further static identifier, |#Self| expands to static type of
>>>>> the code it appears within, completing the ways code may want to
>>>>> refer to the type it is declared in.
>>>>>
>>>>> *
>>>>>
>>>>> |#Self| expands to the static type of the code it is declared
>>>>> within. In value types, this is always the same as |Self|. In
>>>>> reference types, it refers to the declaring type. |#Self| will
>>>>> offer a literal textual replacement just like |#file|, etc.
>>>>>
>>>>> At Chris's suggestion, I'm starting a new SE thread to see
>>>>> whether there remains any interest for including #Self in the
>>>>> language. I'm personally happy with the SE-0068 outcome but I
>>>>> didn't want to undercut anyone like Timothy Wood who had
>>>>> originally spoken up for its inclusion.
>>>>>
>>>>> -- E
>>>>>
>>>>> _______________________________________________ swift-evolution
>>>>> mailing list swift-evolution at swift.org
>>>>> <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>>
>>> _______________________________________________ swift-evolution
>>> mailing list swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>> _______________________________________________ swift-evolution
>> mailing list swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>