<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 8, 2016, at 23:47, L. Mihalkovic <<a href="mailto:laurent.mihalkovic@gmail.com" class="">laurent.mihalkovic@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><br class=""><br class=""><div class="">Regards</div>(From<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "> mobile)</span></div><div class=""><br class="">On Jul 9, 2016, at 6:39 AM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class="">[Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md</a> ]<div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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 <i class="">also</i> has a required initializer for dynamic construction, so that they could write something like this:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">internal struct ModelContext { /*…*/ }</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><br class=""></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">public class ModelBase {</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""> internal required init(context: ModelContext) { /*…*/ }</blockquote><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""> // …</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">}</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">public class SimpleModel: ModelBase {</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""> internal required init(context: ModelContext) { /*…*/ }</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">}</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">public class MoreComplicatedModel: ModelBase { /*…*/ }</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><br class=""></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">// (within some other type)</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">public func instantiateModelObject<Model: ModelBase>(_ type: Model) -> Model {</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""> return type.init(context: self.context)</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">}</blockquote><div class=""><br class=""></div>That is, a <i class="">public</i> entry point calls a required initializer with an <i class="">internal</i> argument type. This is the only way to instantiate Model objects, and the internal context type doesn’t leak out into the public API.</div></blockquote><div class=""><br class=""></div><div class=""><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Then could it be that in the end it is the entire scaffolding that is poorly structured and in need of fixing, rather than altering the language to make the scaffolding work?</span></div></div></div></div></blockquote><br class=""></div><div>I’m afraid it isn’t my codebase, so I can’t speak to this directly, but I don’t see anything wrong with this pattern. Dynamic initialization is useful, and internal, component-specific context is hardly uncommon; if the library used either of these alone we would likely have no problem with it. Two features not composing well does sometimes indicate a flaw in the design.</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>