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

[Tino Heth]

>> Safety is valued, but Swift cares (and should care!) about pragmatism as well… the most obvious example that comes to my mind are arrays, which have no safeguards that stop you from accessing elements that aren't there.
> 
> I'm not sure I understand this point. First, a guaranteed runtime trap on an out-of-bounds index is a *massive* safety improvement over what we had in C/C++/Objective-C.
… but still, it wouldn't it be much safer to return an optional?

> Second, safety is explicitly goal #1 for Swift; it's even more important than performance and expressiveness (although fortunately these aren't always at odds).
Reality is more complicated, and it's hard to measure safety — sometimes it is not even possible to compare two different solutions in terms of general safety.
In the array-example, safety doesn't trump over performance & convenience, and I wouldn't want to use a language without such exceptions (which would mean that even a infinitesimally increase in safety would justify a huge loss in performance, expressiveness and convenience).

> I've made some notes of the arguments (pro and con) that I've seen in this thread and elsewhere; see them below. I think we have seen ample evidence in support for most of them, from both sides. As usual, our differences are difficult/impossible to reconcile. People may have become a bit theatrical at times, but the discussions I've read have been far from dogmatic.
Well, there are some of us who could reconcile their differences — simply be choosing neither sealed nor extendable to be the default… imho this would be the best match for the situation, but "force override" doesn't seem to gain much interest.

I would have chosen a different order, but overall, imho your list looks like you honestly tried to avoid bias — and maybe even achieved this high goal.
Only two tiny additions:
> - The Weirdo Argument: This list represents a very curious subset of Swift developers, who are very different to the vast majority of people using Swift. Normal people just want to get their work done, and they would be infuriated if such a change would be implemented. This list is a quite exotic bubble, and it can be fatal to assume that it is representative for the mass of developers that have to deal with the consequences of its discussions. Programming languages are best evolved in a strictly democratic manner.
As this point closely matches my wording, I have to correct it.
I never said Swift should be evolved in a democratic manner at all, and I absolutely don't think it should.
What I said is that the members of this list are not representative for the majority of developers using Swift, because only a small and somewhat uniform subset is inclined to take part in the discussions.
I guess it's save to assume that there some common characteristics which are much less dominant outside this circle:
- Interest in language design
- A certain degree of theoretical background
- A stable opinion on how software should be written
- Spending time for theoretical discussions instead of developing actual software ;-)
So, this list is definitely some sort of ivory tower, and there is a constant danger for Swift to become a language that pleases a small elite, but ignores the needs of the majority — and I think that Swift specifically aims for the majority.
I myself enjoy over-engineering my code and discard working solutions in favor for a more elegant design, but I know that this is not representative, and I accept reality… and that is that there are many projects built in a fashion that is completely different from how it's said in the books.
"Design for inheritance" is a good idea (not only in theory), but many codebases have hardly any design at all, simply because its author doesn't have enough knowledge to do better.
There is a good motivation to punish bad design, but bad design is quite indifferent about torture, so the only perception of the uninformed developer is that he himself is punished by the language for reasons beyond his interest:
The compiler cannot educate its users, because all they perceive is an annoying call to switch to another file and perform a trivial change.

That's already more text than I wanted to write, but there's still an argument left that's particular important to me:
Choice of defaults is a statement, and therefor relevant for the character of the language — and what this proposal says about Swift is "keep control to yourself, restrict other developers and focus on concealment".
For me, those aren't traits worth striving for.

Tino