On 20.09.2016 19:03, Charles Srstka wrote:
On Sep 20, 2016, at 10:56 AM, Vladimir.S via swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Then, shouldn't we disallow protocol conformance 'in-place' in type's
definition? So, if you need to conform to protocol - only extension is
the syntax for this. In this case I can understand the idea. Otherwise -
can't.

You can’t completely restrict protocol conformance to extensions, because
extensions can’t contained stored properties. Thus, to satisfy a protocol
requirement with a stored property, it must be placed in the type’s definition.

Oh, yes, of course.. And as soon as we can have default implementations for props also - this solution can't help compiler to notify us if our property defined as implementation for protocol requirement is not playing this role any more. Or we we need stored properties in extensions for this idea. As I understand, there were some discussions regarding this.

In any case the solution "protocol conformance in extensions" does not help when we deal with protocol default implementations - we can't say to compiler that this method/prop here exactly as implementation for protocol, not helper method. I.e. in this situation:

protocol A {
    func foov()
}

protocol B : A {
}

extension A {
    func foov() {}
}

extension B {
    // I was expecting this is a default implementation of foov() for B
    // but in reality this is a helper method
    // who knows when this error will be detected
    func foow() {}
}

I think protocol programming should not be so fragile as it is now and so compiler should help in any place where it can help. For now I don't see any better idea than require here some keyword like `override` or `implement`.


Charles

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to