iex> map = %{x: 1}
iex> map.x
1
iex> map.x()
1
Why would anyone use the map.x() syntax for getting map value? I’d suggest deprecating it since it is misleading. Elixir compiler can add IO.warn to map clause when this happens in runtime
2 Likes
Isn’t this just a constraint of parsing/syntax? In your example, it’s not possible to know whether map.x() is a key lookup on a map, or a function call on a module, until runtime. I don’t believe this could ever be a compile-time warning. (I also generally disagree that it’s misleading/etc. even though I agree that map.x() is uncommon.)
1 Like
In this case map would be a variable, not an atom. Variables and atoms should be distinguishable at compile time, no?
While I could be mistaken, I don’t believe the distinction you’re making actually exists. Consider this function:
def call_x(thing)
thing.x()
end
This will work if you pass a module with an x/0 exported or a map.
Good point. Though this is a call to variable whose value is an anonymous function and not a functional call on a module… still sounds like a complicating matter To be fair, that could also be a reason for desiring the proposal since thing.x() the variable pointing to an anonymous function and the thing.x() a variable that is a map could both produce results… we could talk about likeliness, but not impossible either.
[EDIT: Nevermind… ignore the above… there are clearly nuances here I’m not correctly considering.]
@hst337 it is already deprecated when we detect it is a map at compilation time:
Interactive Elixir (1.15.0-dev) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> defmodule Foo do
...(1)> def bar(map) when is_map(map) do
...(1)> map.foo()
...(1)> end
...(1)> end
warning: incompatible types:
map() !~ atom()
in expression:
# iex:3
map.foo()
where "map" was given the type map() in:
# iex:2
is_map(map)
where "map" was given the type atom() (due to calling var.fun()) in:
# iex:3
map.foo()
HINT: "var.field" (without parentheses) implies "var" is a map() while "var.fun()" (with parentheses) implies "var" is an atom()
Conflict found at
iex:3: Foo.bar/1
We have been planning on adding a runtime deprecation for a while and there is an open issue tracking this. 
4 Likes
module.function(1, 2, 3) # Is a call
module.function(1) # Is also a call
module.function() # Is a call and also a map lookup
This is the “misleading” I am talking about
It is impossible to know for sure, but compiler is already able to check the types and warn when map.field() is called when map is a map. Plus, runtime warning is okay too.
Great! I am sorry, I didn’t check the issue tracker
3 Likes
