[swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Vladimir.S]

On 06.07.2016 2:11, Chris Lattner via swift-evolution wrote:
> 	* What is your evaluation of the proposal?

Not sure. If we want to be clear about what can be done with public 
class/method outside the module, and I agree this is an important question, 
IMO we should to force a developer to explicitly mark the class/method as 
'public&final' or as 'public&open'. I.e. the developer of module/framework 
should explicitly decide if he/she wants or don't want to allow for 
subclassable/overridable.

If one writes 'public class' - does this means that he/she *decided* to not 
allow subclasses for this class or just *forgot* to decide this?

Also, IMO the suggested 'subclassable class' / 'overridable func' has no 
relations to access scope but to ability for extension of the class. So 
these keywords just should not replace the 'public', but should be used in 
conjunction.

So, my -1 to proposed 'subclassable'\'overridable' as *replacement* for 
'public'. They confuse and not clear if it is public or modifiers for 
'internal' scope.
My +1 to alternatives like 'public(subclassable)' or 'public subclassable'

My 0.0 for the idea of default non-subclassable `public`. I believe it is 
important for developer to decide what should be allowed to his/her public 
class, so Swift should force the developer to explicitely decide this.
My +1 to require 'public(final)' or 'public(subclassable)', not just 'public'.

> 	* Is the problem being addressed significant enough to warrant a change to Swift?
> 	* Does this proposal fit well with the feel and direction of Swift?
> 	* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?