Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
I've implemented this in [https://github.com/nim-lang/Nim/pull/11865](https://github.com/nim-lang/Nim/pull/11865)
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
well nim files are not header files unlike C, C++ (or D's interface di files, which we could think about in nim but that's a separate discussion), so I'm not sure how one could avoid rebuilding main.nim if it imports foo.nim and foo.nim changes only its private procs ; eg foo could define a public template that call private procs. In any case, even if above rule was feasible, that's not really a concern since a import foo {.private.} would just be instructed to rebuild in case foo is modified, because of the {.private.}
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
Private imports would create their own set of conflicting requirements for the goals of incremental compilation. You wouldn't be able to cleanly separate the public interface of a module from its private components that should not trigger a rebuild upon changing.
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
I too think grouping modules is the right way, for the same reasons - private to stay private, not at the user's discretion. What _@Zahary_ suggests in [https://forum.nim-lang.org/t/4293](https://forum.nim-lang.org/t/4293).
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
Hi The Haxe language has that feature, you can see how they did it here: [https://haxe.org/manual/lf-access-control.html](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.
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
I like the idea and would call it `{.exposePrivate.}`, because that is what is does in my understanding.
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
> 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](https://forum.nim-lang.org/t/4296#26730)
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
IMO `include` is good enough.
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
Maybe: import foo {.visibility: private.} Run
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
+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. :-)
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
> 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: * include it once in the program or you can get duplicates, as you said * no way to force full qualification, eg from foo import nil {.private.}
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
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.
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
include foo does this kind of, just need to include it once in the program or you get duplicates.
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
I think import foo {. private .} sticks out enough, but feel free to recommend something else if you have a better suggestion (that is also self-explanatory).
Re: `import foo {.private.}` to allows access to private fields (eg: package-level visibility)
It's a good idea to have an escape hatch, but like all "break the glass" devices it should stick out as the wrong thing to do unless absolutely necessary; not sure how to achieve that, though.