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

[Patrick Smith]

Could protocol Self change to just the first behaviour for classes?

If a conformance absolutely needs to have a method returning ‘only me but not my subclasses’, then it sets that conforming method to be final.


> On 13 May 2016, at 4:38 PM, Vladimir.S <svabox at gmail.com> wrote:
> 
> The proposed StaticSelf when used as `->StaticSelf` in protocol means ‘myself or my some *base* class’. I.e. if this requirement was implemented in one of base classes, any subclass automatically conforms to the protocol as it has `->(myself or some base class)` in his hierarchy.
> 
> This is the difference with `->Self` in protocol which requires 'myself'.
> 
> On 13.05.2016 7:21, Patrick Smith via swift-evolution wrote:
>> 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
>> 
>> _______________________________________________ swift-evolution mailing
>> list swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>