I for one would very much like this discussion to start again. Yes it was discussed. Unfortunately, it was discussed in a summer time when in my country at least, many of us are off the grid for vacation. This is not a criticism of the process of course, just an indication that not everyone may have had the chance to voice their concerns.
As I expressed it already, even after reading all the arguments for the decision, I stand convinced that this decision is a tragic mistake. Note that I agree with many of the given rationales. I just think that the decision doesn't follow. I will not rehash everything, but I will make a couple of points that may not have been expressed stridently enough: - many many many people expressed contrary voices, and where shut up by the core team's expressing their opinion in favor of preventing subclassability by default. See a small sample at http://mjtsai.com/blog/2016/07/17/swift-classes-to-be-non-publicly-subclassable-by-default/ - One reason I (and others) gave is that I would not trust any programmer (least of which myself) to have the double sight ability to foresee every use of their classes/libraries. One disingenuous answer to that was "if you don't trust the programmer, why do you use their code to begin with?". Well, I don't trust my spouse's ability to forecast the time it takes to drive from place A to place B. Yet I will not break up over that. Time and time again, I have heard Apple executives praise us developers for the use of Apple's technology that they would never have foreseen. This decision goes totally contrary to those praises. This decision is bad, not because it makes the default for classes to be unsubclassable, but because it puts the power of final decision into the wrong hands: the library author's. As a result, guidelines everywhere will eventually mandate for library authors to make everything "open", exactly as the guidelines for public C++ classes is often to make methods virtual. This will nullify much of the benefits of the decision. The final programmer, the client programmer who uses the class should have the final say. The class author is entitled to express "beware, you will likely shoot yourself in the foot". But the final programmer should have the power to answer "thanks for saying. Now give me that gun." My hope is that we can give back the final say to the final programmer through an additive Swift evolution proposal down the line, which would explicitly allow her to "force open" a closed class. I believe that such an addition would right the wrong while still keeping he benefits of the decision. I don't think that such a proposal would affect the ABI, so it seems to me this is not yet the time to come up with such a proposal. I may be wrong on that though: I am quite unclear on what does or does not affect the ABI. To conclude let me give you an anecdote: I was writing this in-house iPhone app for a client, that used the common UITabViewController UI model. We had 5 tabs and 5 icons and all was good. Then the client asked for a new feature into a new 6th tab and wanted a 6th icon to be squeezed in the tab bar. The Apple's UI guidelines the, and the UITabViewController class precluded that (it may have changed since, I haven't developed for iOS in quite a while). However user testing showed that it was quite OK to put 6 icons there. I was able to subclass UITabViewController to accommodate for that, despite the fact the it was not only not designed for that, but also actively designed to prevent that. Now there are many reasons why it could be claimed that what I did was wrong. And I would agree with those I suspect. However, that I could do it (pondering all factors) was actually the difference between "yes but" and "no way". As a result, my customer was another happy Apple user. With Swift and that decision, this would not have happened, and we would all have been the poorer for it. I hope I that this additive proposal I mentioned above can see the light of day in due time. Best regards, Jean-Denis > On Aug 14, 2016, at 14:26, Goffredo Marocchi via swift-evolution > <swift-evolution@swift.org> wrote: > > You are not familiar with us Italians and our love for (hopefully reasonable) > arguing I see ;). I commit to and accept the decision taken, but it remains > a decision I disagree with and something that will probably birth a painful > fork once say Android and/or other big corporations moved to Swift and > decided for example that they wanted a new set of rules. > > Sent from my iPhone > >> On 14 Aug 2016, at 11:14, Jean-Daniel Dupas via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> Le 14 août 2016 à 11:17, John Holdsworth via swift-evolution >>> <swift-evolution@swift.org> a écrit : >>> >>> Hi folks, >>> >>> I see from building the latest Swift-3.0 branch that I’m a little behind >>> the times and this proposal has been accepted :( >>> >>> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md >>> >>> Is there no way we can revisit this decision? 60 emails on a mail group not >>> read by the whole community >>> doesn’t quite seem enough validation for such a significant change to me. >> >> 60 emails ? You’re joking. It is more 600 emails than 60 that was send >> about that proposal, and I’m pretty sure nobody want to see that discussion >> start again. >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
