> 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 _______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users