It can already solve it today Add use Boundary to the top-level module (e.g. context), and the cross-boundary calls to the internal ones will be reported. It’s still not fully usable, b/c the support for nested boundaries is lacking, but that’s definitely on the roadmap.

Boundary doesn’t do any mangling. It uses compilation tracer to collect all function/macro invocations, and then reports non-permitted cross-boundary calls.

It’s definitely not bulletproof. Breaking it is currently as easy as using apply to dynamically invoke the function. This can be detected though, and I plan to address it, but even then you can work around by constructing the module name dynamically.

All that said, boundary will make you work harder to introduce unwanted dependencies into your codebase.

It would certainly help stop “accidental” usage where someone who doesn’t understand the @moduledoc false idiom calls a function directly instead of through private api.

The convention is that internal modules are @moduledoc false, similar how internal functions are @doc false, though you have no way to enforce that no one will use them.

There is some prototype library defmodulep which hides modules by name doing some name mangling, but still, once someone figured out the mangled name, they can use the module anyway.

I wonder if boundaries will end up being the way to solve this in future. Make the functions public but enforce that only the parent module can call them outside of tests.