[swift-users] open/public protocol with not overridable default implementation in the future?
Brent Royal-Gordon
brent at architechies.com
Tue Sep 20 16:19:37 CDT 2016
> I always wanted a way to make some protocol default implementations not overridable. Now Swift 3 got open vs. public behavior for classes. (Hopefully the inconsistency will be fixed soon and we’ll get open protocols as well.)
>
> Imagine this scenario with open/public protocols.
>
> // Module A
> // `open protocol` means that in a diff. module I'll
> // be able to conform to that protocol
> open protocol Proto {}
>
> extension Proto {
> // shouldn't this mean that the variable is not overridable
> // from a different module? :)
> public var foo: Int { return 42 }
> }
>
> // Module B
> struct A : Proto {
> // can I or can I not override `foo` from here?
> }
>
> I wonder if my thinking is correct here, or do we need something else to make extensions with default implementation to be fixed and not overridable?
Currently, a declaration of `A.foo` would not *override* `Proto.foo`, it would *shadow* it. Using `foo` on a variable of type `Proto` will always use `Proto`'s implementation. That's why `A.foo`'s declaration will not have the `override` keyword. It's a subtle distinction, but a really important one—if you're expecting a call to `Proto.foo` to instead go to `A.foo`, you're gonna have a bad time.
Personally, I think this is a bad idea, and I'd like to see the compiler reject conformances which cause visible shadowing. But that's a different story. As long as we're allowing this shadowing to pass unremarked, it makes sense that `public` wouldn't prevent it.
--
Brent Royal-Gordon
Architechies
More information about the swift-users
mailing list