> 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@...> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
