> I believe no programmer, least of which myself, can be trusted with the > decision to reliably decide ahead of time that this or that class cannot or > will not be subclassed. > So strong -1 for me.
I just don’t get this line of reasoning. Can a programmer be trusted with determining if a type should be declared as a struct vs. a class? If I choose to implement an API construct with a struct, you’ll be the exact same position that this proposal puts you in with classes as well. I’m a big +1 for this proposal. The default annotations on types should set up code to be as future-proof as possible without putting someone in a bad spot resilience-wise simply because they forgot to add the restriction before shipping. This proposal also does *not* disallow language features that allow unsafe constructs to be added later. Even with this proposal, it’s still possible to add the __unsafe_really_subclass_even_though_its_bad construct. It requires additional metadata to be kept around by the compiler so that any optimizations that may have removed the dynamic dispatching of functions calls through the inheritance chain to be kept, but it’s still possible. -David _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
