I have many situations where related, and usually, nested types should have access to implementation details of each other but I want to avoid any other types having access to these details. The simplest example that I have are value types that wrap one or two values. 'Unrelated' types shouldn't have access to these `rawValue`s at all. TJ
On Fri, Mar 25, 2016 at 12:11 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > > > On Mar 25, 2016, at 10:57 AM, Tino Heth via swift-evolution < > swift-evolution@swift.org> wrote: > > > > > >> These are special cases — both file-private and module-private is > something that is fairly unusual > > > > afaics this is the third time someone mentions that "file-private" is > uncommon — so I think it's time someone dissents: > > That statement is at least subjective… right now, "file-private" is one > of three access levels, and I wouldn't dare to say either is more or less > important than the others. > > > > I never encountered situations with the current model where I missed a > new "private"-level, and maybe "private" will become fairly unusual for the > code I'll be writing. > > > > In my existing code, the new meaning of private wouldn't break much, but > the current meaning doesn't hurt me, and there are cases where > "file-private" is needed. > > > > None the less, I don't care much about the "ugliness" of "fileprivate" — > but not because I perceive it as unusual: > > I just expect that code completion will do the typing for me, so maybe > "f" will be all I have to write (half the characters of "pr" ;-) > > I cannot come up with a single use-case in my code for fileprivate and > would love > some real world examples where you'd want visibility in a single file but > not across > an entire module. > > The fileprivate behavior has been a bugaboo of mine for some time, > particularly in > playground use. > > As far as I'm concerned, the control I really want is public, > intra-modular, private, and > private-even-to-extensions-and-subclasses. I assume the latter is a no-go. > > -- E > > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution