[swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jordan Rose]

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md ]

John has done a tremendous job supporting this proposal; the position he’s articulated very closely matches mine. Thank you to both John and Javier. 

I wanted to share a concrete use case that Daniel Dunbar relayed to me. He was working on a closed class hierarchy like the ones discussed here, where all of the subclasses are within a single module, but they are all public. The class also has a required initializer for dynamic construction, so that they could write something like this:

internal struct ModelContext { /*…*/ }

public class ModelBase {
  internal required init(context: ModelContext) { /*…*/ }
  // …
}
public class SimpleModel: ModelBase {
  internal required init(context: ModelContext) { /*…*/ }
}
public class MoreComplicatedModel: ModelBase { /*…*/ }

// (within some other type)
public func instantiateModelObject<Model: ModelBase>(_ type: Model) -> Model {
  return type.init(context: self.context)
}

That is, a public entry point calls a required initializer with an internal argument type. This is the only way to instantiate Model objects, and the internal context type doesn’t leak out into the public API.

Of course, Swift doesn’t allow this. If someone outside of the module subclasses ModelBase, there’s no way for them to provide the dynamically-dispatched 'init(context:)’, because they don’t have access to the internal ModelContext. The author of the library has to make the required initializers public, and either set the ModelContext separately or make it public as well. Even though no one outside the module should be using these APIs.

If ModelBase were public-but-not-subclassable, however, the code is perfectly fine. The initializer and the helper type don’t need to be public, and clients of the library see only what they need.

This is just one use case. I don’t want to say it’s a general model for everyone’s code. However, it does point to a desire for public-and-not-subclassable classes; any other solution would either require the library author making more things public, or the compiler making it possible to accidentally call an unimplemented initializer.

I’ll send a separate message with my thoughts as the primary author of the Library Evolution model, to keep those discussions distinct. That one will have a bit more ideology in it. :-)

Jordan

P.S. “Why not use protocols?” When a protocol has an initializer requirement, it still forces all subclasses of a conforming class to provide an implementation, i.e. the conforming class’s initializer still needs to be declared ‘required’. That means it’s subject to the same restriction: a required initializer must have as much access as the containing class.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160708/2f002783/attachment.html>