Just to relax a bit, from reading this thread I cannot help but feel a relation to Civil War. One can even say on which side everyone here would stand for real. #TeamIronMan
L On 8 July 2016 at 15:13, Matthew Johnson via swift-evolution <[email protected]> wrote: > > > Sent from my iPad > > On Jul 8, 2016, at 12:30 PM, Tino Heth <[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. > > > I didn't say it isn't dramatic, only that it isn't as dramatic a change as > some commenters seem to suggest. > > 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. > > > It's not about guilt or innocence, or any kind of lenience or punishment. > > It's mostly about whether we want to foster an ecosystem where public API > contracts have been explicitly considered or not. There are some ancillary > benefits as well but those are much less important. > > > Defaults matter, because they transmit a message: > > > I agree. > > 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. > > > In a majority of cases today this openness is better fostered by Github than > "anything goes" public API. > > > 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"? > > > I really wish Objective-C had this feature from the start. I believe there > would have been significant benefits to Apple's platforms and ecosystem. > The reasons for believing (or not believing) this have been discussed in > depth so there isn't a need to rehash them now. > > 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. > > > Actually open by default has caused some very nontrivial difficulties for > Apple's framework maintainers. We all pay the price for this whether we > engage in such subclassing and overriding or not. I find that pretty > unfortunate, especially for those of us who do find other ways to solve our > problems. > > -Matthew > > > _______________________________________________ > 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
