Thanks Booker, We would like to here more complete proposals on the topic. We need to consider the completeness of the mechanism, for example, how can it bypassed? What are the peformance costs? How should Code.ensure_loaded? and function_exported? behave? What are the gotchas?
For example, the proposed syntax is not achievable because Elixir does not require modules to be available at compile time when you only invoke them at runtime. So when any code invokes ExUnit.CliFormatter inside the function definition, we don't check for it at all.And if we start checking it for all invocations, it may incur big compilation time costs. *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D On Wed, Aug 1, 2018 at 5:39 PM, Booker Bense <bbe...@gmail.com> 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 elixir-lang-core+unsubscr...@googlegroups.com. > 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 elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BZ_7ijRiVeFrt%2BwBZiEvOs0iL4u-WpwYH%3DJ4SGOkgc1w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
