> On Feb 17, 2017, at 9:48 AM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > > What you are really asking for is a way of flexibly designating a "unit of > code" within a module, for which the general solution is submodules. The > objection is that, instead of tackling that issue, these are suggestions to > invent ad-hoc units of code (scope + extensions only in the same file, scope > + extensions only in the same module, class + extensions only in the same > file + subclasses only in the same module), and it is possible to invent > arbitrary many of these. > > There is, objectively, an actual minimum number of access modifiers, which is > two. Those two are: visible only inside the unit of code, or visible both > inside and outside the unit of code. In Swift, those are spelled internal and > public. Everything else here is really talking about better or more flexible > ways of defining a unit of code.
Wasn’t there a thread about submodules a while back? I’m pretty sure I remember reading some back and forth about it here, but I don’t recall any conclusions. - Dave Sweeris _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
