# Making subclassing more flexible **URL:** \ **Category:** Discussion\ **Created:** [October 30, 2023, 11:32pm UTC](https://forums.swift.org/t/making-subclassing-more-flexible/68156 "2023-10-30T23:32:41Z")\ **Posts on this page:** 1\ **Showing post:** 7
**Author:** ![beccadax](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/beccadax/32/34217_2.png) [@beccadax](https://forums.swift.org/u/beccadax)\ **Post date:** [October 31, 2023, 4:56am UTC](https://forums.swift.org/t/making-subclassing-more-flexible/68156/7 "2023-10-31T04:56:37Z")
> [@davdroman](#): > > My proposal assumes there's a chance to fix it for good as part of Swift 6. 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](https://forums.swift.org/t/design-priorities-for-the-swift-6-language-mode/62408) thread: > [@Design Priorities for the Swift 6 Language Mode](https://forums.swift.org/t/design-priorities-for-the-swift-6-language-mode/62408/1): > > Swift 6 must not change the fundamental shape of the language, nor make sweeping changes without purpose. Rather, it should only introduce changes that serve a specific goal that benefits the entire Swift ecosystem and is not achievable while maintaining source compatibility. 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. --- _[View the full topic](https://forums.swift.org/t/making-subclassing-more-flexible/68156)._