Please close this issue if it doesn't make sense, it just seems to me this could be improved at the language level. 👍🏼
As this tweet points out, you can call defmodule passing true or false as a module name:
defmodule false, do: def foo, do: "bar"
> false.foo
"bar"
The point is not about $handle_undefined_function – an erlang feature mentioned in the tweet but beyond the scope of this ticket – but about allowing these module names to be defined.
As much as true and false are just atoms in the end of the day, I think defmodule would be a bit more robust if it doesn't allow these to be defined as module names, just as it does with nil.
The same when you call defmodule nil, fail:
iex(5)> defmodule nil, do: def a, do: 1
** (ArgumentError) cannot invoke def/2 outside module
(elixir) lib/kernel.ex:5362: Kernel.assert_module_scope/3
(elixir) lib/kernel.ex:4101: Kernel.define/4
(elixir) expanding macro: Kernel.def/2
iex:5: (file)
The way defmodule nil fails is also terrible. If we want to forbid special atoms to be module names I think we should do it by returning a nicer error.
Agree, we should forbid those three and raise nice error messages.
@rodrigues do you want to work on a PR that adds this? :)
@whatyouhide yes sirrr, just don't know if I can do it, hehehe, gonna take a look at it tonight 👍🏼
@rodrigues of course, no rush. Please feel free to ping us here or on IRC or the Elixir Slack if you need some help or guidance. :)
Closing in favor of the PR.
Most helpful comment
Agree, we should forbid those three and raise nice error messages.