I could see it as a warning now and a hard error in Elixir 2.0. Effectively a deprecation warning.
blatyo
Conduit Core Team
Cochonours
As it is explicit, I do not think it is a problem. It looks like in C++ where you can have private members accessed by friend classes.
0
NobbZ
So you want to deprecate the use of things that shouldn’t have been used from the start, because the developer tried their best to hide the function or module from you?
Again, we are only talking about making it harder to access things you shouldn’t have accessed at all, we are not talking about magic that breaks everything in existence…
4
dimitarvp
That is exactly what “backwards incompatible” is not. You consciously choose to use a new addition to the language. No legacy code will be broken.
1
josevalim
Creator of Elixir
If someone is using a private API (which is @doc false today), they are in no place to put a burden of the maintainers of that library. The author of said libraries are free to move the private code around, rename private functions, or remove private modules as they wish. This is a non-discussion for me. 
9
dimitarvp
I heavily lean towards option C:
However, I’d also prefer if next Elixir version adds a function like Module.get_private/1 that hardcodes the implementation detail logic of :"Elixirp.Foo.Bar". Better for the core team not to bind themselves to a hardcoded logic which might not endure the test of time. But maybe I am overthinking it. So far they always knew very well what they were doing.
In any case, having the option to do iex debugging in prod environments has been, and must continue to be, one of the best selling points of Elixir.
2
scarfacedeb
I’m ok with C.
Although I’d prefer having @visible_to as module attribute, instead of an option to defmodulep.
I got used to @moduledoc, @behaviour, @type and other special attributes. And having another extra one seems more natural than an option for me.
2
dimitarvp
It’s too easy for people to forget to put a module attribute in. Requiring it in defmodulep leaves them no such option.
0
NobbZ
No need to, as you would require Foo.Bar, as: Private.
:"Elixirp.Foo.Bar" is a fallback hatch, a back door if you want, to be able to access the module during development or debugging sessions in prod through iex.
0
dimitarvp
Exactly my point. I am little uncomfortable with us having to compose the exact atom module name in prod iex settings. Having a convenience escape-hatch function/macro loses us nothing and, again, clearly communicates your intent. It can also help when testing such modules (although testing implementation details should be a no-go by default).
As I said above though, I would not insist on it. Just a small quality-of-life improvement, nothing major.
0