-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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to