[swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

[Patrick Smith]

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 <swift-evolution at swift.org> wrote:
> 
> 
>> On May 12, 2016, at 5:49 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution