Unexpected BadMapError when calling function via module variable

[slashmili]

Elixir and Erlang/OTP versions

I’ve encountered a behavior change in Elixir 1.20.0-rc.3 compared to 1.19.

The following code works as expected in Elixir 1.19, but fails in 1.20.0-rc.3:

defmodule Hello do
  def hi do
    :hello
  end
end

defmodule HelloTest do
  use ExUnit.Case, async: true

  test "calling function" do
    assert Hello.hi() == :hello

    assert mod_names() |> Enum.map(&(&1.hi == :hello))
  end

  def mod_names do
    [Hello]
  end
end

I understand that this code is strange, but that's what I have in one of my projects and the tests are not passing because in this project has many codes like this pattern.

Operating system

linux

Expected behavior

elixir --version
Erlang/OTP 28 [erts-16.2] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit:ns]

Elixir 1.19.2 (compiled with Erlang/OTP 28)

mix test --trace test/hello_test.exs
Running ExUnit with seed: 132941, max_cases: 1


HelloTest [test/hello_test.exs]
  * test calling function [L#10]warning: using map.field notation (without parentheses) to invoke function Hello.hi() is deprecated, you must add parentheses instead: remote.function()
  test/hello_test.exs:13: anonymous fn/1 in HelloTest."test calling function"/1
  (elixir 1.19.2) lib/enum.ex:1688: Enum."-map/2-lists^map/1-1-"/2
  test/hello_test.exs:13: HelloTest."test calling function"/1
  (ex_unit 1.19.2) lib/ex_unit/runner.ex:528: ExUnit.Runner.exec_test/2
  (stdlib 7.2) timer.erl:599: :timer.tc/2
  (ex_unit 1.19.2) lib/ex_unit/runner.ex:450: anonymous fn/6 in ExUnit.Runner.spawn_test_monitor/4

  * test calling function (8.0ms) [L#10]

Finished in 0.03 seconds (0.03s async, 0.00s sync)
1 test, 0 failures

Current behavior

elixir --version
Erlang/OTP 28 [erts-16.2] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit:ns]

Elixir 1.20.0-rc.3 (2db87eb) (compiled with Erlang/OTP 28)

mix test --trace test/hello_test.exs
Running ExUnit with seed: 703652, max_cases: 1


HelloTest [test/hello_test.exs]
  * test calling function (2.3ms) [L#10]

  1) test calling function (HelloTest)
     test/hello_test.exs:10
     ** (BadMapError) expected a map, got:

         Hello

     code: assert mod_names() |> Enum.map(&(&1.hi == :hello))
     stacktrace:
       test/hello_test.exs:13: anonymous fn/1 in HelloTest."test calling function"/1
       (elixir 1.20.0-rc.3) lib/enum.ex:1725: Enum."-map/2-lists^map/1-1-"/2
       test/hello_test.exs:13: (test)


Finished in 0.01 seconds (0.01s async, 0.00s sync)
1 test, 1 failure

[sabiwara]

@slashmili thank you for the report, but this is an intentional breaking change which is documented in the Changelog.

map.foo() (accessing a map field with parens) and mod.foo (invoking a function without parens) will now raise instead of emitting runtime warnings, aligning themselves with the type system behaviour.

[josevalim]

Btw, it was supposed to be emitting warnings for several past releases. Perhaps IO is being captured or something?

[sabiwara]

@josevalim I thought so too but it didn't seem to be the case - accessing a map with a call was doing it though (in 1.19.3 using livebook):

defmodule Foo do
  def ok do
    # neither compile time nor runtime warning
    :math.pi
  end
  
  def nok1 do
    # both compile time and runtime warnings
    # runtime:
    # warning: using map.field notation (without parentheses) to invoke function :math.pi() is deprecated, you must add parentheses instead: remote.function()
    mod = :math
    mod.pi
  end

  def nok2 do
    # compile time only warning
    map = %{pi: 1}
    map.pi()
  end
end

[slashmili]

Thanks for the clarification!

I understand this is an intentional change and that it’s documented. I just wanted to share some feedback from the perspective of existing codebases.

While I personally wouldn’t write code in this style since Elixir ~1.10, patterns like this do exist in the wild, and this change turns what was previously a warning into a hard failure in a minor version bump. That makes upgrades a bit more disruptive than expected, particularly for larger codebases where this pattern may appear in many places.

I completely see the motivation for aligning with the type system and making the behavior stricter. I just wanted to raise the concern that this might benefit from either a longer deprecation cycle or clearer upgrade guidance, since it can cause test failures in otherwise working code.

Thanks again for the work on Elixir!

[josevalim]

I thought it was emitting a warning before, if it wasn't, we need to revert it.