[swift-evolution] A Comprehensive Rethink of Access Levels in Swift

[Rien]

Ah, the irony…

Having argued against too much complexity, I now encountered an error in my software that shows why there might indeed be a need for “open” and “public”.

In an API:

class Foo {
  open func foo(options: Option ...) {
    foo(options)
  }
  open func foo(options: [Options]) { … }
}

An API user might do this:

class Bar: Foo {
  override func foo(options: Option ...) {
    …
    super.foo(options)
  }
}

var b = Bar()
b.foo(options: [Option.thisOne])

This compiles fine, and will even work .... up to a point where the additions in Bar.foo are essential. Then it fails.
The user should have called:  b.foo(options: Option.thisOne)

This can easily be prevented by making Foo.foo(options: Option) public instead of open.
Then the user would not have been able to override the convenience method.
Furthermore: the user would not have experienced any inconvenience either as Foo.foo() would still be usable.

The interesting thing is that in this case there is no real argument on the side of the API developer to have a need for either open or public. It is entirely to the benefit of the API user. To me that makes a case for having both open and public. As an API developer I am willing to “go the extra mile” to create a good user experience, even if that means using tricks to achieve that end. However that would be impossible in this case. This end-user convenience is only achievable through open and public.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl