[Late Pitch] open/public protocols


(Adrian Zubarev) #1

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 :confused:
  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


Constrain protocol usage outside the module
(Tino) #2

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.

At least it is very, very similar, and most of the syntax is identical.
Considering the demand for "sealed" protocols, imho this inconsistency should be addressed as soon as possible.

Afair, the decision for "public as restriction of open" happened quite quickly… I guess simply adding "sealed" would have spared Swift from a huge, breaking change and avoided the protocol-issue as well.

Tino


(Kevin Lundberg) #3

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.

I don't understand why this is the case. From a practical perspective,
non-open classes by default were pushed in order to guard against the
fragile base class problem. Classes always carry implementations with
the methods you can override, while protocols don't (in the same way). A
"fragile base protocol extension implementation" problem can be avoided
today by designing your protocols properly. Not to mention that by
definition, protocols are designed to be conformed to by other types,
while not all classes are designed to be subclassed. What problem aside
from a perceived inconsistency would allowing for non-open protocols by
default solve?

  * |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 :confused: 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() {} } |

This example is a little confusing; do you mean that if protocols are
given the same open semantics as classes that there would be a
cross-module implementation problem? If so, isn't that an argument
against this?

I don't see a problem with just letting the class's open/public modifier
be the last word on any implemented public protocols. If a public
protocol is applied to an open class, then that protocol method should
be allowed to be declared as either open or public, which should be
enough to satisfy the protocol conformance from the protocol's perspective.

···

On 8/22/2016 2:40 PM, Adrian Zubarev via swift-evolution wrote:

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
https://lists.swift.org/mailman/listinfo/swift-evolution


(Karl) #4

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.

Karl

···

On 22 Aug 2016, at 20:40, Adrian Zubarev via swift-evolution <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 :confused:
  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


(John McCall) #5

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.

···

On Aug 25, 2016, at 2:29 AM, Karl via swift-evolution <swift-evolution@swift.org> wrote:

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 :confused:
  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

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


(Adrian Zubarev) #6

Shall we revive this discussion?

···

--
Adrian Zubarev
Sent with Airmail

Am 25. August 2016 um 19:29:13, John McCall (rjmccall@apple.com) schrieb:

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> 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 :confused:
  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
https://lists.swift.org/mailman/listinfo/swift-evolution

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


(Goffredo Marocchi) #7

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@swift.org> wrote:

Shall we revive this discussion?

--
Adrian Zubarev
Sent with Airmail

Am 25. August 2016 um 19:29:13, John McCall (rjmccall@apple.com) schrieb:

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> 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 :confused:
  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
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


(John McCall) #8

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+

It sounds like you're talking about re-opening the public/open class discussion, which is not the discussion I understand Adrian to be asking about.

If people would like to talk about adding some way to express a protocol that can be implemented only internally but still used elsewhere, they should feel free. The core team isn't inviting that kind of formal proposal yet, but that shouldn't prevent any discussion here. However, please understand that changing the interpretation of "public" would be a source-breaking change and therefore needs to meet a much higher bar in 4.0 than it would have in 3.0; that may significantly shape your discussion.

John.

···

On Oct 7, 2016, at 10:44 AM, Goffredo Marocchi <panajev@gmail.com> wrote:

Sent from my iPhone

On 7 Oct 2016, at 17:40, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Shall we revive this discussion?

--
Adrian Zubarev
Sent with Airmail

Am 25. August 2016 um 19:29:13, John McCall (rjmccall@apple.com <mailto:rjmccall@apple.com>) schrieb:

On Aug 25, 2016, at 2:29 AM, Karl via swift-evolution <swift-evolution@swift.org <mailto: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 :confused:
  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

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

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


(Sean Heber) #9

I don’t disagree that there may have been some hasty movement on this originally, but I don’t think the solution is to move hastily again and second-guess everything before the dust has even had time to settle.

l8r
Sean

···

On Oct 7, 2016, at 12:44 PM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

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@swift.org> wrote:

Shall we revive this discussion?

--
Adrian Zubarev
Sent with Airmail

Am 25. August 2016 um 19:29:13, John McCall (rjmccall@apple.com) schrieb:

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> 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 :confused:
  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
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

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


(Goffredo Marocchi) #10

True too, but dust settling will mean that for each speck the justification burden will rise quite massively. Not fixing this for Swift 4 phase 1 may mean a breaking change very very hard to justify for Swift 4 phase 2 which is for additive changes IIRC and even harder for Swift 5 and harder again on Swift 6 unless I am missing the core team vision for Swift's evolution.

···

Sent from my iPhone

On 7 Oct 2016, at 18:50, Sean Heber <sean@fifthace.com> wrote:

I don’t disagree that there may have been some hasty movement on this originally, but I don’t think the solution is to move hastily again and second-guess everything before the dust has even had time to settle.

l8r
Sean

On Oct 7, 2016, at 12:44 PM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

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@swift.org> wrote:

Shall we revive this discussion?

--
Adrian Zubarev
Sent with Airmail

Am 25. August 2016 um 19:29:13, John McCall (rjmccall@apple.com) schrieb:

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> 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 :confused:
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
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

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


(Chris Lattner) #11

We haven’t planned what Swift 4 phase 2 will be, but I am pretty sure that important model changes will always be considered. That said, reopening this discussion only makes sense if there is no insight or information. “fileprivate” and “open” were both *extensively* discussed when the decision was made, I don’t think they were “rushed”.

-Chris

···

On Oct 7, 2016, at 11:05 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

True too, but dust settling will mean that for each speck the justification burden will rise quite massively. Not fixing this for Swift 4 phase 1 may mean a breaking change very very hard to justify for Swift 4 phase 2 which is for additive changes IIRC and even harder for Swift 5 and harder again on Swift 6 unless I am missing the core team vision for Swift's evolution.