On Apr 3, 2017, at 8:11 PM, Nevin Brackett-Rozinsky via swift-evolution <[email protected]> wrote:
> My remaining hope is that Swift will acquire a submodule design which renders > “fileprivate” essentially redundant. If we get an access level that means > “visible in a group of tightly-related files” and it has a concise spelling, > then I will use that just about exclusively. You mean a namespace? Ask some greybeard C++ developers how that one worked out. Honestly, regardless of names, I see the following needs: 1. Keep your mitts off this code, this is for me alone. You will break things if you change this. 2. This one is for me and my relatives who know what we're doing with it. 3. This is for my group as we work together on this problem. 4. This is for anyone that wants us to solve this problem for them. 5. This is for anyone that wants to try to solve this problem some other way. (private, protected, internal, public, open — perhaps?) What we call them matters little, as long as none of those names are fileprivate. 🙂 File-based access control is so very ‘70s (and this is coming from someone who has used C for a Very Long Time and loves it more than Swift, honestly). For *this* language, it’s the wrong tool. We have those new-fangled hierarchical types and extensions all in those fancy little modules, so let’s use them as the people expect them to be used. When submodules are A Thing, revisit them in terms of the “definitions" above and see where things fit. If we — heaven forbid — think we need an additional “export” keyword then we’ll have that firefight then. — Adam
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
