You are correct that this is not a very agile - people over processes - move.
Sent from my iPhone > On 8 Jul 2016, at 18:30, Tino Heth via swift-evolution > <[email protected]> wrote: > > >> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
