Joe Groff

@jckarter You’re saying no change for Apple Swift frameworks because you consider the API, but it’s about protecting others who don’t?

@mjtsai Many users would prematurely reach for 'final' to get a similar effect and be stuck with it w/o the new default behavior.

@jckarter I would have thought you could revoke a final across a module boundary because clients can’t inline, anyway.

@mjtsai 'final' also influences things like dynamic casts and protocol conformance. e.g. Don't need to be covariant if there's no subtyping.

@jckarter @mjtsai In our SDK we re-built final with runtime checks in initialize and just assert to protect people from doing unwise things.

@steipete @mjtsai That's quite a bit of work to do for every API, and requires a lot of runtime knowledge to do well correctly.

@jckarter @steipete @mjtsai main problem with sealed-by-default: makes using stuff for unanticipated use case hard, thus stunts innovation.

@fzwob @steipete @mjtsai Having to support bugs forever for compatibility also stifles innovation. There's tradeoffs.

@jckarter I don’t understand why you have to support bugs (rather than the promised contract) forever. Why not warn like with deprecation?

@mjtsai If subclassing is part of that contract, you have a lot more compatibility surface area to ensure subclassers don't break.

@jckarter I mean in general—undocumented/unpromised subclassing details and non-subclassing-related bugs.