Deprecate map.field() syntax suggestion

hst337

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

6 comments

#operators #dot

2 523 6

2023-01-30 14:18:12 UTC

Showing Posts 1 to 6

Show Best Posts
Show All (oldest first)
Show All (newest first)

zachallaun

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.)

Post #1

sbuttgereit

In this case map would be a variable, not an atom. Variables and atoms should be distinguishable at compile time, no?

Post #2

zachallaun

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.

Post #3

sbuttgereit

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.]

Post #4

josevalim

Creator of Elixir

@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.

Post #5

hst337

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.