dwark

dwark

The following code results in a warning that is difficult for me to understand:

defmodule Mod do
  def hello(name) do
    map = Map.new(words: ["world"])

    IO.inspect(length(map.words), label: :before)
    map = %{map | words: [name | map.words]}
    IO.inspect(length(map.words), label: :after)
  end
end

This yields the following warning:

warning: incompatible types:

    %{words: [var1 | var2]} !~ %{words: var2}

in expression:

    # lib/mod.ex:7
    map.words

where "map" was given the type %{words: [var1 | var2], words: var2, optional(dynamic()) => dynamic()} in:

    # lib/mod.ex:6
    map = %{map | words: [name | map.words]}

where "map" was given the type %{words: [var1 | var2], optional(dynamic()) => dynamic()} (due to calling var.field) in:

    # lib/mod.ex:7
    map.words

HINT: "var.field" (without parentheses) implies "var" is a map() while "var.fun()" (with parentheses) implies "var" is an atom()

Conflict found at
  lib/mod.ex:7

The warning goes away if:

  1. The first IO.inspect with label: :before is commented out. Then the following two
    lines (6 and 7) are not longer at odds with each other type-wise.

  2. OR: Leave the IO.inspect as-is, but change the line following it (the map update) to
    one of the following:

map = %{map | words: [name] ++ map.words}
# or
map = %{map | words: [name | map[:words]]}
  1. OR: Use a struct instead of a dynamic map.

  2. OR: change the first IO.inspect to inspect map[:words] instead of map.words

So the warning is about conflicting types for %{words: [var1 | var2]} !~ %{words: var2}

  • line 6 → %{words: [var1 | var2], words: var2, optional(dynamic()) => dynamic()}
  • line 7 → %{words: [var1 | var2], optional(dynamic()) => dynamic()}

both mention optional(dynamic()) => dynamic(), the first seemingly only for var2 in the prepending of the list, the latter for the list itself?

In both cases, map is a (dynamic) map, the atom key :words’s value is a list so I expected
both to be of the same type, since [var1 | var2] is prepending var1 to the list var2,
much like the [var1] ++ var2 variant. This is what confuses me.

It all seems related to using the dot-notation to access an atom key in a dynamic map.

The docs say:

To access atom keys, one may also use the map.key notation. Note that map.key will raise a KeyError if the map doesn’t contain the key :key , compared to map[:key] , that would return nil .

as well as:

The two syntaxes for accessing keys reveal the dual nature of maps. The map[key] syntax is used for dynamically created maps that may have any key, of any type. map.key is used with maps that hold a predetermined set of atoms keys, which are expected to always be present. Structs, defined via defstruct/1, are one example of such “static maps”, where the keys can also be checked during compile time.

So should I read the above to always use map[key] for dynamic maps even if the key is an atom, and map.key only for static maps like a struct?

Showing Posts 1 to 3

sabiwara

sabiwara

Elixir Core Team

The code seems fine, I think this one is a bug in the compiler.

Opened an issue: Incorrect incompatible type warning on map dot access · Issue #13335 · elixir-lang/elixir · GitHub

dwark

dwark OP

Ok, thanks.

dwark

dwark OP

For future readers: this was already fixed in 1.16 (I was on 1.15.7).

— All posts loaded —

Where Next? Top

Trending in Questions Top

stjefim
Hello! Suppose you are building workflow (order / task / payment) processing system with the following requirements: Each workflow con...
New
water
I’m aware of 2 such projects, are there others? git: GitHub - team-alembic/realworld: A fullstack Phoenix LiveView application with back...
New
peck
Hi everyone. My team and I have been working on a fairly modest app based around video streaming and chat, but we’ve landed a customer t...
New
bradley
I really like the adapter patterns that ecto, nebulex, waffle, etc. use and would love find something similar for a key management servic...
New
unaware8150
Hello folks! So at work, we are seeing some situations where we have to define some “fixed” strings that are used across the codebase in...
New
leoschweizer
Hi, we run different LLM models across a cluster, with each node loading a configurable subset. Model-specific queues let nodes consume ...
New
csmr
Hi all, I’m new here and would like to hear peoples views on my Elixir/Phoenix based game-engine! :smiley: Mutonex gamedesign was finish...
New

Other Trending Topics Top

mudasobwa
I fully migrated to my own harness from Anthropic/Gemini and I think it’s time to share it. Welcome DSH, the DeepSeek Harness, fully writ...
New
KristerV
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
juhalehtonen
There has been a thread to discuss the Stack Overflow Developer Survey on this forum every year since 2018, so here’s yet another one for...
New
webofbits
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself. My main conc...
#ai
New
budgie
I love Elixir. It’s one of 2 programming languages I’ve ever fallen in love with. But I don’t use it anymore. Serverless was the promis...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews