I use the file-private scope a fair amount for top-level constants that are intended to be used within the file, possibly across types. Doing things this way is more concise than embedding them as static members in the type itself since I don't need to qualify them with the name of the type at the front.
Kevin Lundberg ke...@klundberg.com > On Mar 25, 2016, at 1: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
