No warning, no error. Just look at the sentence right before the example you quoted here 
So not even any switches necessary as @Eiji asks for.
NobbZ
lpil
Creator of Gleam
Lovely! I’ll put the kettle on and await your arrival 
I’m voting C, though would prefer it if a warning was printed when the module atom is called directly.
2
NobbZ
lpil
Creator of Gleam
It’d be trivial to add a warning for :"Elixirp.Whatever".call(), just check what the prefix of the atom is after parsing in the compiler.
I’m not suggesting that mod = :"Elixirp.Whatever"; mod.call() print a warning.
1
josevalim
Creator of Elixir
Unfortunately that may have false positives. For example, if you do this:
require SomethingPrivate, as: Private
some_macro(Private)
And then some_macro(Private) calls Macro.expand and returns a quoted expression that calls something on the expanded atom. We would need to track if the atom came from the context or written by the user but atoms do not have metadata. Alternatively it could be done in the parser but that’s likely not the time or place it to do it.
5
derekkraan
Currently we signal private modules with @moduledoc false. A isn’t much different from this, only includes a warning.
In B, you say:
you have no official ways of accessing a private module beyond its original intent.
But, there is still a way: copy and paste the source code into your own function. Maybe this isn’t so bad?
0
LostKobrakai
The critical usages outside the original intent is when you’re debugging at runtime. I’m not sure copy/pasting is any option for that usecase.
5
derekkraan
That’s true, but maybe developers will make public modules to help with debugging if the private modules are completely unavailable. It’s something that people will consider when applying defmodulep.
0
tcoopman
I like this goal of outlining boundaries and communicating intent explicitly! For that reason I don’t think really locking down all possible workarounds is necessary.
I think my current option goes to C and D (public namespace). I’m picking this because I find the defmodulep with visible_to syntax communicates intent more obviously than @module_visible_to. The public namespaces makes sure that exploring and iex still work.
I’m not sure I like the require part, although an other possible advantage of the require part is that it makes the user of a module explicit.
No real preference on errors over warnings.
0
imetallica
I think privateing modules will be a cure worse than the disease.
- It breaks the semantics of the language.
defp(an alias for defprivate) doesn’t allow access to functions outside the module, butdefmodulepallows explicit visibility to some modules. Another naming is required. - I think that we should use an annotation, such as:
@visible_to: [Foobar]or@scoped_to: [Bar]instead (maybe other names), to tag that this module is not for public usage. This should solve (1). - Although already a rejected idea, what we want to do is to guarantee that private modules are not accessible outside the application/package/library/younameit they are included, which is exactly what we are trying to do here.
Given my ideas, commenting on the proposals:
A. I like this idea, but with another name: @visible_to [MyApp, Foo, ...]. And if any module not in that list tries to use, import or whatever it will be a compilation error, much like what happens when you try to call a defp function outside the module you are defining it.
B, C & D. No because of breaking semantics: explained in (1).
6