> 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
