With these names we lose consistency. The current scheme makes it very clear that each next level is a subset of the previous level. With "internal", fileprivate looks out of place.
We have several goals for all the names: 1) obvious 2) using standard terms 3) short 4) consistent This discussion shows that we cannot have all of them. We have to pick something at the expense of something else. For me, the order of importance is 2, 4, 1, 3, and I am pretty sure that with this order public moduleprivate fileprivate private is the best so far. public internal fileprivate private is not as consistent. It's also not as obvious, given that many people proposed to use internal to mean fileprivate. The biggest advantages of these names are that there is less change and short words. If these are the most important goals, then my original proposal is even better: public internal private scoped It's a non-breaking change, everything retains its meaning, the added name is very clear, and all the names are very short. The biggest problem here is "private" -- it's not the most private that the language provides, and most people would expect that. Here is another one like that (it solves the "private" problem at the expense of using non-standard terms): public internal local scoped My main point is that we cannot have everything. We have to pick the order of importance. We heard many times that "short" is not the goal of Swift. Instead, it's clarity. If this is the case, then I think public moduleprivate fileprivate private is the clearest we've seen. Nobody could possibly be confused about the meaning of these names. I doubt that moduleprivate will be required to spell out in any style guide, but even so, it's not so bad. We have many frequently used class names that are much longer. On Thu, Mar 31, 2016 at 12:22 AM Chris Lattner via swift-evolution < [email protected]> wrote: > On Mar 23, 2016, at 10:13 PM, Chris Lattner <[email protected]> wrote: > > How about we continue this trend, and follow other existing Swift > keywords that merge two lowercase words (associatedtype, typealias, etc), > and use: > > > > public > > moduleprivate > > fileprivate > > private > > > > The advantages, as I see them are: > > 1) We keep public and private meaning the “right” and “obvious” things. > > 2) The declmodifiers “read” correctly. > > 3) The unusual ones (moduleprivate and fileprivate) don’t use the > awkward parenthesized keyword approach. > > 4) The unusual ones would be “googable”. > > 5) Support for named submodules could be “dropped in” by putting the > submodule name/path in parens: private(foo.bar.baz) or > moduleprivate(foo.bar). Putting an identifier in the parens is much more > natural than putting keywords in parens. > > I’ve seen a number of concerns on this list about moduleprivate, and how > it penalizes folks who want to explicitly write their access control. I’ve > come to think that there is yes-another possible path forward here (which I > haven’t seen mentioned so far): > > public > internal > fileprivate > private > > The advantages, as I see them are: > 1) We keep public and private meaning the “right” and “obvious” things. > 2) The declmodifiers “read” correctly. > 3) Compared to Swift 2, there is almost no change. The only thing that > changes is that some uses of Swift 2 “private” will be migrated to > “fileprivate”, which makes the intent of the code much more clear. > 4) fileprivate is the unusual and > not-really-precedented-in-other-languages modifier, and it would still be > “googable”. > 5) The addresses the “excessively long” declmodifier problem that several > people are concerned with. > 6) Support for named submodules could be “dropped in” by parameterizing > “internal”. > > Thoughts? > > -Chris > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
