Elixir v1.14.0-rc.1 released

Elixir News & Announcements Elixir News
1

Hi everyone,

The next (and hopefully last) release candidate for Elixir v1.14 is out: Release v1.14.0-rc.1 · elixir-lang/elixir · GitHub

You can read the complete release notes/CHANGELOG here.

Please give this version a try and help us ensure Elixir v1.14.0 won’t have any regressions and work as expected for everyone! To try it out, you may need to either use a package manager or compile from source.

Thank you!

50 Likes
3

Thanks! At first glance, compilation times seems to have improved a little bit on my M1 macbook pro.

[EDIT]

I’m really liking dbg(). A simple search-and-replace of IO.inspect and console output is 10x better.

2 Likes
4

As expected :wink: no problems with Earmark/Parser :clap:

1 Like
5

for asdf users: already available

4 Likes
6

Both of these code fragments …

  if Version.match?(System.version(), ">= 1.14.0-dev") do
    @color_aliases Application.compile_env(:bunt, :color_aliases, [])
  else
    @color_aliases Application.get_env(:bunt, :color_aliases, [])
  end

  if Version.match?(System.version(), ">= 1.14.0-dev") do
    import Bitwise
  else
    use Bitwise
  end

… give me compiler warnings on the v1.14.0-rc.1:

==> bunt
Compiling 2 files (.ex)
warning: Application.get_env/3 is discouraged in the module body, use Application.compile_env/3 instead
  lib/bunt_ansi.ex:300: Bunt.ANSI

Generated bunt app

==> bunt
Compiling 2 files (.ex)
warning: Application.get_env/3 is discouraged in the module body, use Application.compile_env/3 instead
  lib/bunt_ansi.ex:300: Bunt.ANSI

Generated bunt app

Please note that the warnings concern code paths that are not executed due to the version check.

Is this supposed to happen? If so, how are library authors supposed to handle backwards compatibility going forward?

1 Like
7

It would be absolutely amazing if we can solve this, so easy, but at the same time think how Elixir compiler could handle, for example:

if apply(Version, :match?, [System.version(), ">= 1.14.0-dev"]) do
  @color_aliases Application.compile_env(:bunt, :color_aliases, [])
else
  @color_aliases Application.get_env(:bunt, :color_aliases, [])
end

If I would be in such need then I would simply write a macro for it, for example:

defmodule MyLib do
  defmacro __using__(_opts \\ []) do
    if Version.match?(System.version(), ">= 1.14.0-dev") do
      quote do
        @color_aliases Application.compile_env(:bunt, :color_aliases, [])
      end
    else
      quote do
        @color_aliases Application.get_env(:bunt, :color_aliases, [])
      end
    end
  end
end

defmodule MyApp do
  use MyLib
end

With such macro there is no error, as always one of those quoted expressions is never used.

1 Like
8

That’s what I had suggested on github as well in a little more abstracted form:

2 Likes
9

I’d be curious if the compiler could be smart enough if there would be a macro version to compare elixir version expectations and the condition would become if true | false do …

10

I‘ve seen your suggestion, but this has never been a problem in the past.

The macro solution looks like a very opaque and indirect way of going about this.

@josevalim This is a compile-time warning for code that never gets executed (deterministically). What‘s your take on this?

11

The warnings come from Code expansion, not Code execution, so it looks across all clauses always (and has done so for quite some time).

The Bitwise one is easy, because you can use import and it will work on previous versions as well. For the application env, you could do:

function = :get_env
@color_aliases apply(Application, function, [:bunt, :color_aliases, []])

to trick the Elixir compiler.

3 Likes
12

Will do!