> On Aug 25, 2016, at 2:29 AM, Karl via swift-evolution > <swift-evolution@swift.org> wrote: > This is not a new inconsistency. We’ve known about this since “open” was > first proposed. > > Having sealed protocols would be nice, but it’s too late for Swift 3 IMO.
Everything is too late for Swift 3. Bug fixes are about to be too late for Swift 3, much less any actual language changes. John. > > Karl > >> On 22 Aug 2016, at 20:40, Adrian Zubarev via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Hello dear Swift community, >> >> I was updating some of my libraries where I noticed that the new open access >> modifier made the public modifier inconsistent in one way. >> >> Conformances to protocols is logically the same as inheritances on classes. >> >> Conformances == (abstract) inheritance >> That said we should allow protocols to be open/public like we now allow this >> distinction for classes. >> >> open protocol from module A should mean that I’m allowed to conform to it in >> module B >> public protocol will act as an interface in module B >> Not only sounds this behavior like ‘nice to have’, it’s inconsistency and >> it’s a ‘really need’ + a source breaking change in general. >> >> A common mistake in Swift 3.0 would be to hide protocol members behind >> public modifier for protocols that meant to be open. If a protocol member in >> an open class is disallowed to be overridden by the public modifier and this >> behavior is fixed, that will imply that you’ll have to open the member which >> you intended to be not overridable. >> >> // Before: >> >> // In module A >> public protocol Proto { >> func doSomething() >> } >> >> open class Base : Proto { >> // Dissallow to override - this would be a common mistake >> public func doSomething() {} >> } >> >> // Used in module B - so it should be `open` after all >> class Test : Proto { >> func doSomething() {} >> } >> >> // After: >> // In module A >> open protocol Proto { >> func doSomething() >> } >> >> open class Base : Proto { >> // Whops we have to grant the ability to override this method now >> // I made a mistake designing my protocol in Swift 3.0 :/ >> open func doSomething() {} >> } >> >> // In module B >> class Test2 : Base { >> // Uuuuuuh I can do bad things with this now if the module A was not >> redesigned to fix this. :))) >> override func doSomething() {} >> } >> Personally I don’t have any feeling of how huge the impact might be on Swift >> if this behavior will be fixed. I also cannot tell if it’s something for >> Swift 3.x or Swift 4.0. >> >> >> >> >> -- >> Adrian Zubarev >> Sent with Airmail >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
