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?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
