[swift-evolution] [Pitch] open/public protocols

[Goffredo Marocchi]

I would say we should, I think we moved a bit hastily and the strict push for non subclassable by default and the sealed by default discussion may still yield nasty side effects that are exponentially costlier as we move to Swift 4+

Sent from my iPhone

> On 7 Oct 2016, at 17:40, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Shall we revive this discussion?
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 25. August 2016 um 19:29:13, John McCall (rjmccall at apple.com) schrieb:
> 
>>> On Aug 25, 2016, at 2:29 AM, Karl via swift-evolution <swift-evolution at 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 at 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 at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161007/3781c7e0/attachment.html>