<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Feb 25, 2017, at 12:12 AM, David Waite via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class=""><blockquote type="cite" class="">On Feb 23, 2017, at 2:56 PM, Nevin Brackett-Rozinsky via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</blockquote></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><div class=""><div class="">The prevailing view from recent discussions is that there should be just one access level more fine-grained than ‘internal’, and it should be spelled ‘private’. Let us leave aside for the moment what its exact meaning should be, and consider the other end of the scale.</div></div></div></div></div></blockquote><div><br class=""></div>I think the submodule discussion now goes against this being a prevailing view - submodules are directly tied to be an access control level *above* private/fileprivate.</div><div><br class=""></div><div>My expectation is that with submodules, “fileprivate” would go away.</div><div><div><br class=""></div></div><div><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><div class="">Moreover, object-oriented programming is just as much a first-class citizen in Swift as protocol-oriented programming is, so we should treat it as such. Classes are inherently inheritable: when one writes “class Foo {}”, then Foo has a default visibility of ‘internal’, and by default it can have subclasses. That is a straightforward model, and it is easy to work with.</div></div></div></blockquote><div><br class=""></div>There is nothing about OOP which requires subclass-based polymorphism. Rust and Go are two examples of modern languages that do not support subclassing at all.</div><div><br class=""></div><div>In reality, there is less agreement on what “Object Oriented Programming” means to technologists than there is about the real meaning of “Moore’s Law"</div><div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><div class="">One of the reasons ‘public’ was previously chosen for closed classes is to provide a “soft default” for library authors, so they can prevent subclassing until they decide later whether to allow it in a future release. This is a misguided decision, as it prioritizes the convenience of library authors over the productivity of application developers. Library authors have a responsibility to decide what interfaces they present, and we should not encourage them to release libraries without making those decisions.</div></div></div></blockquote><div><br class=""></div>I think SE-0117 and the discussion behind it is pretty clear about why this is the default. It is not about convenience, but safety.<br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""></div><div class="">Moreover, we need to trust client programmers to make reasonable choices. If a library mistakenly allows subclassing when it shouldn’t, all a client has to do to work with it correctly is *not make subclasses*. The library is still usable. Conversely, if a library mistakenly prohibits subclassing, then there are things a client *should* be able to do but cannot. The harm to the users of a library is greater in this last case, because the ability to use the library is compromised, and that diminishes their productivity.</div></div></div></blockquote><div><br class=""></div>If a client uses a library type which was never intended to be subclassed and subclasses it, the only options to take the library forward are to:</div><div>1. break the client</div><div>2. make that usage part of your supported API, and work around any issues that causes</div><div><br class=""></div><div>I sympathize with app developers under deadlines. I wouldn’t mind Swift having an ‘escape hatch’ to let an app developer take responsibility and to then abuse a library’s access levels (if that were possible without restricting optimizations in the Swift compiler). But closed-by-default is safer, and lets poorly specified libraries evolve to be higher quality libraries without breaking existing usage that they never intended to support.</div><div><br class=""></div><div><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><div class="">We should not make “soft defaults” that tend to negatively impact the clients of a library for the dubious benefit of enabling its author to procrastinate on a basic design decision. If someone truly wants to publish a library with a closed class, then we should support that. But it should be an intentional decision, not a default.</div></div></div></blockquote><div><br class=""></div><div>If you were proposing the default for public classes be final rather than closed, I would be on-board with that line of thinking.</div><div><br class=""></div><div>If you proposed that final was redundant and should go away, leaving just public and public open, I’d find that defensible (I think even with closed as a default, it is useful to indicate within am module that a class is subclassed or not) </div><div><br class=""></div><div>If you proposed that library authors should be forced into a decision, and should get a warning with a default of final until they label public classes as open or final or sealsed, I’d also be on-board with that option.</div><div><div class=""><br class=""></div></div><div>However, “open by default” is quite different than “final by default”. The default for structs and enums are final by default. Protocols are implementable, but they by definition should have defined semantics for doing so. Open-by-default subclasses have the potential to be modified in ways you were never expected, then handed back to you. Exposing a class the same way you would expose a struct, enum, or protocol and having it directly impact your resiliency because you forgot to also add “final” is just not as safe. I think the SE-0117 discussion covered this *very* well.</div><div><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><div class=""><b class="">Motivation – Rethinking ‘private’</b></div><div class=""><br class=""></div><div class="">Now let us return to ‘private’, which as discussed earlier should be the only modifier that is tighter than ‘internal’. The purpose of ‘private’ is to enable encapsulation of related code, without revealing implementation details to the rest of the module. It should be compatible with using extensions to build up types, and it should not encourage overly-long files.</div></div></div></blockquote><div><br class=""></div>As said before, I think this is an incorrect conclusion. </div><div><br class=""></div><div>My personal thinking has been swayed over the last few months, and I’ve gone from vehemently opposing private to seeing merit in it. I believe my opposition was not against scoped private, but that it both kept fileprivate as a required access level and a redundant one, because it was not part of a larger change. </div><div><br class=""></div><div>Swift need a modifier between private and internal, and “fileprivate” is neither the feature we want, nor the spelling. Fileprivate should have been replaced with a more appropriate access level between private and internal, to represent ‘friend” relationships. I think we may be now looking at doing that, with submodules. </div></div></blockquote><div><br></div><div>I would love to hear your feedback on my submodule proposal David! I believe it addresses the use cases you're describing very well.</div><blockquote type="cite"><div><div><br class=""></div><div><div class="">My tact is that keywords should first and foremost document developer intent.</div><div class=""><br class=""></div><div class="">If I were to say which members of a type *should* be private, it would be the members that are not properly designed to uphold class invariance. Allowing access to write a negative integer to a property that should only ever be positive would be a good example. Calling a member without holding a lock or first dispatching onto the right GCD queue would be another.</div><div class=""><br class=""></div><div class="">In that context, a private which restricts even same-file, build-up extensions could be a positive language feature, because the extensions are being built using the safer interface. This is a trade-off, as some interfaces (NSCoding is a prime example) may require access to members otherwise made private.</div><div class=""><br class=""></div></div><div><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><div class="">The natural definition, therefore, is that ‘private’ should mean “visible in a small group of files which belong together as a unit”. Of course Swift does not yet have submodules, and is not likely to gain them this year. However, if we say that each file is implicitly its own submodule unless otherwise specified, then the model works. In that view, ‘private’ will mean “visible in this submodule”, and for the time being that is synonymous with “visible in this file”.</div></div></div></blockquote><div><br class=""></div>I think internal is a more appropriate visibility within a submodule.</div><div><br class=""></div><div>-DW</div><div><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>