[swift-evolution] [RFC] #Self

[Matthew Johnson]

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

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

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.

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

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