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

Sean Heber sean at fifthace.com
Mon Dec 7 14:10:10 CST 2015

> This would be much better than current behavior, but I still favor final by default.  I really believe inheritance and overridability is part of an API contract that should be explicitly stated in code even for code within a module.  This enhances readability, encourages thoughtful design, and prevents unintentional interfaces.

It is almost like there’s potential for a third fundamental “type." We have “struct” and “class” and they represent “value” and “reference", but often what one simply wants or needs is, more or less, just a pointer to a struct. If a 3rd type existed, classes could be reserved for “this is for subclassing, you must override methods, call super, etc”, and value types/structs remain as they are with their copying semantics, etc. and the third type would be, essentially, a sealed/final kind of class - but with it’s own distinct name and rules rather than being considered a “class" in the usual sense.

struct Foo {
 // value type, no subclassing

class Bar {
 // reference type, must considering subclassing (enforced calling super, etc?)

handle Baz {
 // reference type, no subclassing

I haven’t thought about this a lot - maybe it’s silly. :)


More information about the swift-evolution mailing list