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

[Vladimir.S]

On 13.05.2016 9:45, Patrick Smith wrote:
> 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.

Hm.. Do we *need* to change `->Self` behavior? It actually depends on what 
such requirement will mean for classes. Right now it is '->return instance 
of self class'. If we all agree that it should means '->return instance of 
self class or of any base class' - then we obviously can require such a 
change.

>
>
>> 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
>>>
>
>