> How would this look in the exported API? Would it simply show itself as not > inheriting from anything? If your base class inherited from something (e.g. > NSObject), would the public subclasses show themselves as direct subclasses > of that superclass (NSObject)? I wouldn't care, but the last option sounds sensible (although I hope I'll never have to directly subclass NSObject in the future ;-)
> IMHO these things can be solved by private protocols with default > implementation to reuse the code: Not everything can be solved with protocols (stored properties, anyone?) > Or you can just create a private class and use its instance in your classes: > > internal class MyClassImplementation { > /// Implement shared code > } > > public class MyClass { > private var _impl = MyClassImplementation() > } > Which is fairly common solution. Those six lines are written easily, but they don't do anything, so you have to add tons of boilerplate to do forwarding — and you destroy the internal class hierarchy. Do you see a problem with "internal init"? > Anyway, this is definitely out of scope of Swift 3 and as has been pointed > out several times in the past month here, all discussions here should now > focus on Swift 3 features. Sorry, I've been busy with other things lately… I know that anything that breaks compatibility with existing source has top priority now, and that there most likely won't be any resources to integrate stuff that doesn't fulfill that criterion — but has there been an actual announcement that no discussions about purely additive changes should be started at all? Best regards, Tino _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution