Making subclassing more flexible

While it’s not totally forbidden to break source compatibility in a major language version, there are still balancing tests to determine if a break is worth the cost, and I don’t think this would clear that hurdle. Consider this bit from January’s Design Priorities for the Swift 6 Language Mode thread:

Changing open merely because you don’t like the current design would be a “sweeping change without purpose”. On the other hand, allowing subclassing of package declarations is “achievable while maintaining source compatibility” by choosing an alternate spelling, like open(package), that doesn’t affect any existing meanings. So either way, making open orthogonal to other access levels is probably not a viable proposal.

1 Like