Elixir v1.17.0-rc.0 released

I see; I did think it was the problem that affected a lot of OTP 26 functionality in Windows last fall, and which I was very glad got fixed. I haven’t run into this issue.

(well, I’m still not sure what issue. I did see the linked issue about Ctrl-C breaking the terminal, and I run into that all the time but I have a little batch file to fix it when it happens, and it wouldn’t happen to an end user. The batch file to fix that goes like this:

call "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvarsall.bat" amd64

chcp 65001

Most likely the chcp 65001 is the only thing that’s needed; the other line is so nmake works but I haven’t checked to see.

using map.field notation (without parentheses) to invoke X is deprecated, you must add parentheses instead

Does anyone know a quick way to suppress this? This warning is drowning out other logs.

Doesn’t mix format solve this?

It is warning about code in the deps.

Oh, yeah - it’s often thing when you update your Elixir version. Well … you don’t need to see logs of dependencies, so maybe simply call mix deps.compile and mix compile separately then? After first one you can just clear your console. :see_no_evil:


At the moment, Elixir developers will interact with set-theoretic types only through warnings found by the type system.

I’d love to test out the new type system and see the new warnings. I tried an example based on the reference document, but I think I must be doing something wrong:

defmodule Test do
  def negate(x) when is_integer(x), do: -x
  def negate(x) when is_boolean(x), do: not x

  def test() do
    IO.puts negate(1)
    IO.puts negate(true)
    # warning expected?
    IO.puts negate("Hello")

Compile Output:

$ mix compile --force
Compiling 1 file (.ex)
Generated test_elixir_types app

Mix version:

$ mix --version
Erlang/OTP 26 [erts-14.2.5] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit:ns]

Mix 1.17.0-rc.0 (a2600ea) (compiled with Erlang/OTP 26)

Any ideas on what I’m missing?


I have same results. It’s just a start and not everything is covered yet. However if you need to debug such mistakes you can try using dialyxir. :link:

I noticed this too but on a re-read, I believe the opening paragraph of the Warnings from gradual set-theoretic types is slightly confusing and not meant to mean all patterns and guard. I believe it’s just examples in the second bulleted list that work (as in my experimenting everything there works).


Has anyone been able to reproduce this ecto issue on 1.17? I’ll test it out on Tuesday, but I’m curious if it is expected to be resolved.

I can only suggest opening an issue in the relevant deps.

As a library writer I try to get ahead of the elixir release curve, but typically only work in earnest at the first release candidate (so now for Elixir 1.17). I suspect that’s true for other library writers too.


At least for one of them, yes :slight_smile:


We only infer types from patterns defined in the same function. Therefore, the example above won’t work yet because:

  1. your type information is coming from guards
  2. it is defined in a separate function

The example you provided will work either by 1.18 or by 1.19. :slight_smile:


Not sure if this is an issue in Elixir 1.17 or not, but warnings related to Absinthe are failing the build of our project with the --warnings-as-errors flag.

As I’m sure everyone is aware, that flag usually only fails the build if the project itself contains warnings.

This is the issue opened with Absinthe:

You probably should not have --warnings-as-errors when compiling dependencies, as you have little control over dependencies’ code. Instead I prefer to first run mix deps.compile (without --warnings-as-errors) and then mix compile --warnings-as-errors to get warning-errors only from my application code.


This is correct, --warnings-as-errors should only be failing if the warnings is emitting when compiling the project, not its dependencies.

In this case, I suspect this is because of meta programming - the library is probably generating code which gets compiled when compiling the project.

Instead I prefer to first run mix deps.compile (without --warnings-as-errors) and then mix compile --warnings-as-errors to get warning-errors only from my application code.

This should be the same as just running mix compile --warnings-as-errors, for the reason mentioned above.

1 Like

Here is a very hacky way of suppressing the ubiquitous warning (bash shell) in the log output only (it will still fail warnings-as-errors compilation).

mix test 2>&1 | awk '/you must add parentheses instead/{p=0} /^$/{p=1} p'

quick hand-wavey explanation:

  • 2> means "redirect the error output, usually called stderr
  • &1 refers to stdout
  • awk does awk things. Run man awk in your shell for more info.

NB: This redirects all warnings/errors to the stdout. Also you won’t get the nice green dots appearing 1-by-1. They will all appear at the same time (probably with no color).


Any plan to add support for the new Erlang JSON module?


I have just started testing apps against Elixir 1.17.0-rc.0 and it’s going well. Bravo to the Elixir core team!!!

1 Like