Does Nim need package-level visibility? - Nim forum suggested introducing package-level visibility and gave proper rationale for why something like that; however, as noted, it would add complexity to the language (eg: no syntax for that was suggested and it's not clear how to extend the simple * for package-level visibility; likely a macro {.pkg.} would be needed.
Instead, I'd like to suggest something simpler:import foo {.private.} (syntax can be discussed) which imports symbols in foo, as if they were declared public, eg:
foo.nim:
type Bar* = object
field1*: int
field2: float
proc bar(a:int): int = ...
tfoo.nim:
import foo {.private.}
doAssert bar(10) == 10 # we can access `bar` thanks to `{.private.}` pragma
The idea is to provide an escape hatch to visibility, and the user of {.private.} knows what he's doing. In particular, changes to private symbols are still allowed and are not considered breaking changes.
Since typically {.private.} would be used within boundaries of a library, this wouldn't result in actual breakages.
Additional use cases are enabled by this feature, notably for debugging purposes.
I've edited my comment above while you posted yours ...
With respect to "sticks out enough", I totally agree at the early adopter stage Nim is still in, but totally disagree for the time it reaches more widespread audience (and of course total world domination) - to many programmers, especially from a C++ / Java background, slapping a "private" or "public" onto things until the compiler is happy is a way of life.
include foo does this kind of, just need to include it once in the program or you get duplicates.
include (which is really like C's #include) is very different:
+1 on some kind of invisibility/private-ness override feature. Another bonus of that is to use it as a temporary workaround if some 3rd party package has made something "overly" private as viewed by an "expert" user. While this has come up in the context of library writing, sometimes users of libraries understand many of its internals and sometimes they don't. Private, not exported, is probably the right default or at least too late to change, but it's easy to forget a * export marker and easy to disagree. This proposed mechanism would allow temporary workarounds much closer to a likely more sanitary future usage.
It might be better to call it something scarier/less similar to a token like private which can be so common in other prog.lang's as to lead to questions like "why does private mean this negative sense in Nim but positive sense in Foo?". import foo {.overrideInvisibility.} or overridePrivate or something. Just some kind of word to indicate bypassing of normal-ness (to act as a redundant cue over there being a pragma there at all). I agree that {.breakTheGlassAndMakeEverythingVisible.} is severe overkill. :-)
Maybe:
import foo {.visibility: private.}
IMO include is good enough.
No it's not. I've expanded on why include is not good enough, see my updated post here https://forum.nim-lang.org/t/4296#26730
Hi The Haxe language has that feature, you can see how they did it here: https://haxe.org/manual/lf-access-control.html
you know, learn from their lessons about intended usage. In general, I think it's a mis-feature, since it can break my design. I only found it useful for unit testing, when the tester is in a different module, and you wish to test all the private functions as well. for what it's worth, C# has a related feature, which is the an access modifier called "internal", which means it's public for everything inside the dll (the same assembly) even if it contains numerous namespaces (modules). I think this is a better way, design-wise, though not as flexible as your suggestion.