[swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Matthew Johnson]

> 	* What is your evaluation of the proposal?

+1 to the first design.  I think this is a great solution that balances the many considerations that have been raised on all sides of this issue.  `open` is 2 characters shorter than `public` so complaints about boilerplate are no longer valid.  `internal` is the “default” - neither `public` nor `open` are privileged as a “default” for publishing API outside of a module.  

I am interested in language enhancements such as exhaustive pattern matching on classes and protocols which rely on knowledge of the full class hierarchy.  Such enhancements will be far more useful if the language supports non-open, non-final classes.

There are design techniques that would require additional boilerplate if we cannot have non-open, non-final classes.  

Most importantly, requiring library authors to choose `public` or `open` provides important documentation value.  Users of the library will know whether the author intends to support subclasses or not.  The second design requires the use of comments and / or documentation to communicate this information.  I prefer important semantic considerations like this to be encoded in the language itself.

I would prefer to see better language support for composition to support compositional subclasses rather than choosing the second design here.  Language support for composition could be designed to work with structs as well as classes and would encourage the use of protocols rather than class hierarchies for polymorphism.  This feels like a much Swiftier direction to me.

> 	* Is the problem being addressed significant enough to warrant a change to Swift?

Yes.  Library authors are currently locked into “open” designs unless they are able to make the design `final` and remember to do so in the initial release.

> 	* Does this proposal fit well with the feel and direction of Swift?

Very much so.  It seeks an optimal middle ground that keeps boilerplate to a minimum while providing explicit API contracts.

> 	* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

The closest is the requirement to mark methods as `virtual` in C++ and C#.  This solution is superior in a number of ways.  A couple of items come to mind immediately:

1. It avoids boilerplate within a module allowing for easy rapid prototyping and evolution of a design within a module.
2. It requires an explicit choice to be made when publishing an API which means that a library author can’t accidentally “forget” to include the `open` modifier if that is their intent.

> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

In-depth participation in many of the discussion threads and the initial review thread as well as in-depth study of all relevant proposals.

> 
> More information about the Swift evolution process is available at
> 
> 	https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> _______________________________________________
> swift-evolution-announce mailing list
> swift-evolution-announce at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce