Sent from my iPad
> On Jul 9, 2016, at 3:48 AM, Goffredo Marocchi via swift-evolution > <[email protected]> wrote: > > > Sent from my iPhone > >> On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution >> <[email protected]> wrote: >> >> Even in Java, it is a bad idea to leave classes subclassable; but having to >> remember to add final is a chore. > > I still think it is worth doing that chore. The fact of the matter is that > Java did not and is not enforcing that default and how many widely used > production languages you know that do enforce this by default instead of > asking library authors to do this bit of work? People keep talking about just adding final. This *is not* an alternative. We are not talking about preventing subclasses by default (i.e. final by default). We are talking about preventing subclasses *in other modules* by default (i.e. sealed by default). The alternative would be to introduce a sealed keyword (or similar). There are times when you *need* to use subclasses inside your module. Some or all of them may not even be directly visible externally (class clusters). However, you *do not* want any new subclasses added as you know that is not likely to end well. This is why having sealed, not just final, is important. By choosing sealed as a default rather than final, we are keeping the "subclassable by default" status *within* modules. This facilitates experimentation and eliminates the need for application level code to opt-in to subclassing while still making external API contracts explicit and therefore hopefully more robust. It is the default most in-line with the values and goals of Swift. 'final' and 'sealed' are two very different things. Let's please keep this focused on what is actually being proposed. > > _______________________________________________ > 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
