I have types where I declare their members (some public, some private) and use extensions to provide the API implementations of protocols.
These implementations use data that is not public to the type. A file-based access level is the only one that works for me. This is actually the common case for me. Sent from my iPhone > On Mar 25, 2016, at 10:11 AM, Erica Sadun via swift-evolution > <[email protected]> wrote: > > >> On Mar 25, 2016, at 10:57 AM, Tino Heth via swift-evolution >> <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
