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

[Vladimir.S]

 > I'm not convinced by this example.

Probably my & Matthew's previous discussion in `[swift-evolution] [RFC] 
#Self` topic will help you. I was trying there to find out (in primitive 
examples) what Matthew is trying to achive with this `->StaticSelf` in 
protocol.

In two words - he wants to achieve requirement 'return Self class or any of 
base classes', as current `->Self` requires 'strictly return Self class'

On 13.05.2016 12:46, Nicola Salmoria via swift-evolution wrote:
> Matthew Johnson via swift-evolution <swift-evolution at ...> writes:
>
>> 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
>> }
>
> I'm not convinced by this example.
>
> I think the problem to solve here is the interaction of protocols with
> classes.
> A related issue was illustrated by Tony Allevato here
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502
> /016294.html
>
> I think that before attempting to solve this specific problem introducing a
> new notation, the general design of the interaction between protocols and
> class inheritance should be reviewed.
>
>
> Nicola
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>