[swift-evolution] Final by default for classes and methods

[Rod Brown]

I must agree entirely with Brent’s assessment here.

Can swift be a language that can go down as low-level as high performance computing? Absolutely. But need we tie our hands with the limitations as such? I don’t think so. Safety must give way to sensibility when the costs are this high.


> On 22 Dec 2015, at 5:31 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> In my considerable experience with C++, that is not at all where we are today.  Increasingly, C++ is becoming seen as a language for high-performance computing, and people working in that area learn that they don't want to pay for virtual dispatch when they don't have to.  It is true that for some of them, reflexive use of OOP is hard to shake, but they do learn eventually.
> 
> Is Swift's goal to be a perfect language for high-performance computing? I thought it was to be a language that scales from scripting to systems programming, with a nice sweet spot around application development.
> 
> For application development, speed is certainly good, but it is not the priority. We want Swift to go fast wherever we can get those speed gains without much cost, of course, but I worry that the cost of this proposal is too high. Just imagine going through UIKit and marking every class inheritable *by hand*—no cheating with a script—and you'll have some idea of the additional burden you'll be imposing on developers as they write their code. The proposals that every single method should be explicitly marked as overridable are even worse; frankly, I don't think I'd want to use Swift if you forced me to put a `virtual` keyword on every declaration.
> 
> I worry that the team's use of Swift to build the standard library, and their close association with teams building OS frameworks, is biasing the language a little bit. I think that, in all likelihood, most Swift code is in individual applications, and most libraries are not published outside of a single team. If I'm right, then most Swift code will probably be quite tolerant of small but technically "breaking" ABI changes, such as making a class `final`, or (as mentioned in another thread) making a closure `@noescape`.
> 
> That won't be true of published library code, of course. But published library code is a small minority of the Swift code people will write, and it already will require greater scrutiny and more careful design. 
> 
> There is already a good opportunity to reflect on whether or not an API should be `final`. It's when you put the `public` keyword on it. I think programmers will have a better, easier time writing their code if, in this case, we put a little bit of trust in them, rather than erecting yet another hoop they must jump through.
> 
> Perhaps we could even provide a "strict interfaces" mode that published frameworks can turn on, which would require you to declare the heritability of every class and member. But even that may not be a good idea, because I also suspect that, in the field, most published libraries probably have to be extended in ways the library's author did not expect or anticipate. 
> 
> This means doing some dangerous overriding, yes. But a UI that breaks after an iOS upgrade is not nearly as dangerous to my business as a three-month delay while I reimplement half of UIKit because someone in Cupertino thought they knew what I need better than I do and turned off—or even worse, *left turned off without a single thought*—subclassing of UIBarButtonItem.
> 
> The bottom line is this: Your users like Swift's strictures when they're helpful. *This stricture is not helpful.* Library users don't accidentally subclass things, and with the `override` keyword in Swift, they don't accidentally override them either. And where it truly is important, for safety or for speed, to prevent subclassing, we already have `final`. Making it the default is less safety than suffering.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution