> On May 10, 2016, at 10:34 AM, Vladimir.S via swift-evolution > <swift-evolution@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 <matt...@anandabits.com >>> <mailto:matt...@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution