I didn’t really understand some of the lead in discussion examples regarding protocols A and B each being interwoven, but I would prefer to see StaticSelf only used for concrete types, and protocols only to use Self. If Self has problems with non-final classes, then maybe how it works in protocols could change. A class could interpret a protocol’s ‘Self’ as ‘myself or my subclasses’?
Maybe instead of introducing StaticSelf it could be renamed simply Self, and ‘Self’ as used in protocols could change to something else? ‘Instance’ perhaps? > On 13 May 2016, at 12:21 PM, Joe Groff via swift-evolution > <[email protected]> wrote: > > >> On May 12, 2016, at 5:49 PM, Matthew Johnson via swift-evolution >> <[email protected]> wrote: >> >> The invariant StaticSelf identifier will always refer to A, unlike Self, >> which is covarying and refers to >> the type of the actual instance. Since multiple inheritance for non-protocol >> types is disallowed, >> this establishes this invariant type identifier with no possibility for >> conflict. >> >> Consider the following example, under the current system: >> >> protocol StringCreatable >> { >> >> static func createWithString(s: String) -> Self >> >> } >> >> >> extension NSURL: StringCreatable >> { >> >> // cannot conform because NSURL is non-final >> >> >> // error: method 'createWithString' in non-final class 'NSURL' must return >> `Self` to conform to protocol 'A' >> >> } >> >> Introducing a static, invariant version of Self permits the desired >> conformance: >> >> protocol StringCreatable >> { >> >> static func createWithString(s: String) -> StaticSelf >> >> } >> >> >> extension NSURL: StringCreatable >> { >> >> // can now conform conform because NSURL is fixed and matches the static >> >> >> // type of the conforming construct. Subclasses need not re-implement >> >> >> // NOTE: the return type can be declared as StaticSelf *or* as NSURL >> >> >> // they are interchangeable >> >> >> static func createWithString(s: String) -> StaticSelf >> { >> >> // ... >> >> } >> } >> >> > > As I've noted before, I don't think this makes sense to encode in the > protocol. `Self` is already effectively invariant within a protocol. If a > protocol doesn't have the foresight to use StaticSelf, then you still have > the same problems retroactively conforming class hierarchies to the protocol. > Whether a conformance is inherited or not feels more natural as a property of > a conformance, not something that can be legislated a priori by a protocol > definition. > > Something like StaticSelf might still be useful as shorthand within a class > definition with a long-winded name, though `StaticSelf` feels kind of long as > a shortcut to me. > > -Joe > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
