I agree that it's theoretically okay to hide parts of the hierarchy. It would raise some secondary questions, like how to expose the "public" features of the internal superclass, but we could solve them.
However, it's clearly additive to do this, since it's just lifting a restriction, so please wait to propose this until Swift 3 is complete.
John.
···
On Jul 5, 2016, at 6:48 PM, Karl via swift-evolution <swift-evolution@swift.org> wrote:
On 5 Jul 2016, at 08:49, Andre via swift-evolution <swift-evolution@swift.org> wrote:
Personally, it's perhaps more of an "aesthetic" thing I suppose but I would definitely prefer that my internal classes stay internal even if there is a public subclass... I don't like how that leaks my internal implementation like that...
Though maybe the more swift thing to do would be to use private extensions in place of private superclasses I suppose...
andre
iPhoneから送信
2016/07/04 21:31、Tino Heth via swift-evolution <swift-evolution@swift.org> のメッセージ:
I'm running into "class cannot be declared public because its superclass is internal" issues on a regular basis, and I wonder if it wouldn't make sense to allow this combination:
It might be less useful as soon as there are abstract classes or generic protocols, but even then I think I'd like to have this "feature".Inheritance can be such a private thing ;-), so imho there should be an obvious way to hide it (marking all init-methods internal works, but I don't think this is a good way to express the intention).
Tino
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolutionIt certainly would be nice to selectively hide parts of the class hierarchy.