> 1. As you point out, the majority of the surface area of idiomatic Swift APIs
> are unlikely to be impacted (value types, protocols, and final classes).
> This is very likely to apply to future Swift-native APIs from Apple
> regardless of the outcome of this proposal.
>
> 2. There is no impact on users of Apple's Objective-C APIs (AFAICT).
>
> In the context of these facts, this proposal is not nearly as dramatic a
> change as many seem to be suggesting.
It is dramatic, and your whole argument is flawed because you miss the imho
most important point.
This is not only a question of "will I be able to override this tiny method of
UIView in the future?", but a question of attitude:
When you do away with the rule of lenity and change it to "guilty by default",
the direct impact is marginal as well — but it is a drastic change for the
society as a whole.
Defaults matter, because they transmit a message:
Every rule and obstacle we add to Swift is a statement that says "we favor
bureaucracy over freedom", and this will affect the community evolving around
the language.
When you use a library in a way that wasn't anticipated by its author, you'll
ran into issues occasionally; nonetheless, I think we should struggle for an
open ecosystem that encourages others to experiment and fail, rather than to
limit their possibilities in a futile attempt to protect them.
Everyone should ask himself a simple question:
When was the last time you you thought "I really wish the author of that
library had restricted my options to use it"?
As a matter of fact, open by default forces nobody to subclass and override, so
it's easy to avoid any problems caused by excessive hacking — closed by
default, on the other hand, has impact not only on those who believe in
restrictions, but on those who dislike them as well.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
