It is impossible to do at compile-time, but we have a history of doing checks that only catch stuff at compile-time. For example, xref checks for undefined functions in modules at compile-time (so it will catch Foo.undefined_function(...)), but it won't catch apply(Foo, :undefined_function, [...]). Not saying I am in favour or opposed to this feature, but I think it would be fine to implement from a consistency standpoint.
Andrea Leopardi [email protected] On Wed, Aug 1, 2018 at 6:25 PM 'Justin Wood' via elixir-lang-core < [email protected]> wrote: > Would this be in addition to using @moduledoc false? Or would this be > replacing that? I think the main problem with trying to give warnings to > people about using an internal module is that functions like apply/3 > exist. I think it would be impossible to do it all at compile time. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On 1 August 2018 11:39 AM, Booker Bense <[email protected]> wrote: > > The recent thread on the Elixir forum about the use of "private" modules > (i.e. @moduledoc false) being unsafe to minor upgrades has started me > thinking about a general solution to this problem. > > Given the dynamic nature of the BEAM it would be overly onerous to attempt > to do any kind of runtime "blocking" of modules, but I think a reasonable > compromise would be to have a compile time warning when you call a function > from an "unsafe" module. To enable this private modules would explicitly > list the modules for which the module is safe to be used from. > > For example: > > In ExUnit.CLIFormatter you would add this attribute > > @safe_in [ ExUnit] > > > Note: this may not be a particularly good example, since the formatter is > stored as a config variable. > > The compiler would generate warnings if any functions from the module were > used in any modules not listed in > the @safe_in attribute. This would work for both the core Elixir libraries > and also provide a tool for 3rd party > libraries to be more explicit to their users. > > - Booker C. Bense > > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/76bfebad-2fda-4ec8-b5ee-e12d64053fd2%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/76bfebad-2fda-4ec8-b5ee-e12d64053fd2%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/umsvU3dJ4f4O2MFldHksLgeP_vk9LuxL5p5Cnf9YDtN8vyD6X0Uwaip0GtIKIFsuMR4D1KqxKAqI4UwCK722rCT4SWnmfLhA1lX2N4wbO9Y%3D%40protonmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/umsvU3dJ4f4O2MFldHksLgeP_vk9LuxL5p5Cnf9YDtN8vyD6X0Uwaip0GtIKIFsuMR4D1KqxKAqI4UwCK722rCT4SWnmfLhA1lX2N4wbO9Y%3D%40protonmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAM9Rf%2B%2BM0EPN8X9BoJ27o1ZEh_9fvVfbR-7ONpB3VeitWtM6EA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
