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

Tino Heth 2th at gmx.de
Wed Jul 6 09:31:30 CDT 2016


-1, against all odds.

I can't fight the feeling that many fans of ideas like this believe that good designed libraries come for free by simply adding restrictions — which, at least in my opinion, just isn't true:
No matter what the defaults are, good libraries are hard to build, so I predict this proposal would not only fail in increasing framework quality, but also will make it much harder for users of those frameworks to work around their flaws, which are just a natural part of every software.

The change would be less painful than final by default, and most normal developers wouldn't have to suffer (at least with their own code), but their is still confusion to expect:
When you tell someone about a "subclassable" modifier, the natural expectation is that this is needed for every class you want to subclass...

It's similar with overridable, but additionally, this would destroy a possible way to annotate a method that can be overridden, but not called, which I'd consider as quite useful.
So, at least I vote for a modification that overridable doesn't imply public — not only because it's more powerful, but also because implying things is a complication

> 	* Is the problem being addressed significant enough to warrant a change to Swift?
no, I question there is a problem with the status quo at all

> 	* Does this proposal fit well with the feel and direction of Swift?
(does anyone ever write something here that contradicts his own evaluation? ;-)

> 	* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Not exactly the same, but C++ with its "virtual" is similar (C++ at its time had the excuse of better performance for the inconvenience; I don't think this small benefit should be important for Swift)

> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Just read the proposal and the messages, and took part in similar discussions before

Tino


More information about the swift-evolution mailing list