Sent from my iPad
> On May 10, 2016, at 11:25 AM, Vladimir.S <[email protected]> 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 >>> <[email protected]> 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 >>>>> <[email protected] <mailto:[email protected]>> 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 >>>>> <[email protected] <mailto:sw _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
