It’s not, just depends on the “type” of constant and it’s a whole other convo 
I agree but I was specifically talking about creating a constant and then the only place it’s used is in a function that just returns it.
sodapopcan
sabiwara
Elixir Core Team
@PragTob (shameless plug) You might be interested in this micro lib I made, Cmp, with precisely this issue in mind. It should be safe, fast and should always do the right thing out of the box.
Regarding point 4. and is_map(1..10) == true, we decided to introduce a new is_non_struct_map/1 guard in order to be have a simple and blessed way of checking for this (vs is_map(term) and not is_struct(term)).
Thanks a lot for the amazing article!
5
dimitarvp
Back when I worked with Ruby still, I just added .freeze after the constant’s definition. Helped my team back then much more often than I expected.
0
PragTob
Thanks @sabiwara ! I was literally debating implementing the same thing (from a cursory look) and post a draft of it like: “Any reason not to do this?”. I was gonna name it Comparable, but I see that’s what you called the protocol and yeah, would have done the same. I had been wondering forever why it isn’t done like this/doesn’t exist. So, thanks a lot! 
Awesome, sounds useful - thanks again for all your (& the core teams) hard work!
Pleasure + thanks for calling it out 
I like that (and rubocop suggests it) but it only really fixes a problem with mutability, not with all of them being “public” which isn’t always what you’d want (as I would often just extract constants for naming and even more to avoid wasteful allocations).
1
BartOtten
PragTob
I had been thinking about this as well. nil, true and false being atoms is up for the next edition. I think it’s tougher, I can see non_nil but the booleans being in the mix is also somewhat confusing.
Since atoms should be known at compile time I think you’re usually better off making an explicit check against a list of known atoms though aka in [:a, :b, :c]
3
sasajuric
Author of Elixir In Action
In a way they can. You can provide many of the values from the regular code (i.e. modules in lib). E.g. both, an Ecto repo and a Phoenix endpoint, can accept params as the first arg passed to start_link.
1
josevalim
Creator of Elixir
Exactly. I rarely see the issue with atoms showing up because, when you want an atom, then you either want all atoms, or you expect some atoms, and then you list the ones you want.
Rather the opposite problem is more common: people using booleans to model problems, when atoms would be clearer. But boolean obsession/blindness is not an Elixir specific issue. 
0
BartOtten
How is this much different from maps and structs. You either wants all maps or you pattern match. Still ‘is_map_not_struct’ was added.
Nil is sometimes used as return value for not-existing or undefined (e.g. ecto) so an is_atom check is sometimes used to check if there is a result. Seems to me the guard is not aligned with the expectation of newcomers as mentioning this gotcha receives a lot of love.
-
That nil, true and false are technically atoms is easy to miss as no colons are needed. Their special status might just as well make them excluded from is_atom imho. Then ‘is_atom’ simply means ‘is a colon keyword’ and debugging symbols align with the match syntax.
-
Exceptions for true and false might be considered, but -I- have never seen that mistake.
-
I wonder if excluding nil, false and true from is_atom would be a breaking change in the sense that (I think) most people probably did not want those values to match in the first place.
2
josevalim
Creator of Elixir
The difference is that you can do a lot of things with maps. For example, I can write:
def foo(%{} = map) do
Enum.reduce(map, ..., ...)
end
And that code won’t work for structs or it will work potentially enumerating something else (not tuples representing pairs). Or trying using the access behaviour. You can’t really do many interesting things with atoms besides comparing them, so in my experience, those mix-ups rarely happen. Even in the example you provide, most code checks if something exists or not by precisely checking is_nil/not is_nil (YMMV).
EDIT: That said, we could 100% add a disclaimer to the is_atom/1 guard if there isn’t one yet. Plus this is another scenario that can be caught by the type system because in such cases it would know is_atom/1 would always return true.
It would 100% be a breaking change. For example, implementation of true/false/nil is done via the Atom protocol. So we can’t keep them separate without breaking that. Dialyzer and Erlang as a whole would not share our interpretation of atoms, etc.
3