Elixir v1.20.0-rc.5 released

As usual, this release has additional type checks and performance improvements. Please give it a try. We expect only one additional RC after this one with any pending fixes, so we can release v1.20.0.

Congratulations on the release! Are you interested in false positive type warnings - should we report them as bugs? E.g., I have a piece of HEEX where the type checker complains but stop complaining if I simply change the order

                  <.yinsh_score_ring
                    :for={index <- 1..3}
                    # no complaints if `earned?` is placed here instead
                    # earned?={index <= player.yinsh_rings_removed}
                    id={"#{@id}-#{player.color}-ring-score-#{index}"}
                    color={player.color}
                    earned?={index <= player.yinsh_rings_removed}
                  />

The type warning:

     type warning found at:
     │
 270 │                 earned?={index <= player.yinsh_rings_removed}
     │                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     │
     └─ lib/playgipf_web/components/game_components.ex:270: PlaygipfWeb.GameComponents."game_topbar (overridable 1)"/1

     warning: comparison with structs found:

         index <= player.yinsh_rings_removed

     given types:

         dynamic(
           %{
             ...,
             __struct__:
               Date or DateTime or Decimal or NaiveDateTime or Phoenix.LiveComponent.CID or Postgrex.Copy or
                 Postgrex.Query or Postgrex.TextQuery or Time or URI or Version or Version.Requirement
           } or atom() or bitstring() or empty_list() or float() or integer() or
             non_empty_list(term(), term())
         ) <= dynamic()

     where "index" was given the type:

         # type: dynamic(
           %{
             ...,
             __struct__:
               Date or DateTime or Decimal or NaiveDateTime or Phoenix.LiveComponent.CID or Postgrex.Copy or
                 Postgrex.Query or Postgrex.TextQuery or Time or URI or Version or Version.Requirement
           } or atom() or bitstring() or empty_list() or float() or integer() or
             non_empty_list(term(), term())
         )
         # from: lib/playgipf_web/components/position_components/position_panel.ex:441
         to_string(index)

     where "player" was given the types:

         # type: dynamic(%{..., game_type: term()})
         # from: lib/playgipf_web/components/position_components/position_panel.ex:431
         player.game_type == :yinsh

         # type: dynamic(%{..., game_type: :yinsh})
         # from: lib/playgipf_web/components/position_components/position_panel.ex:431
         player.game_type == :yinsh

         # type: dynamic(%{..., game_type: :yinsh, yinsh_setup?: false})
         # from: lib/playgipf_web/components/position_components/position_panel.ex:431
         not player.yinsh_setup?

         # type: dynamic(%{
           ...,
           color:
             %{
               ...,
               __struct__:
                 Date or DateTime or Decimal or NaiveDateTime or Phoenix.LiveComponent.CID or Postgrex.Copy or
                   Postgrex.Query or Postgrex.TextQuery or Time or URI or Version or Version.Requirement
             } or atom() or bitstring() or empty_list() or float() or integer() or
               non_empty_list(term(), term()),
           game_type: :yinsh,
           yinsh_setup?: false
         })
         # from: lib/playgipf_web/components/position_components/position_panel.ex:441
         to_string(player.color)

     Comparison operators (>, <, >=, <=, min, and max) perform structural and not semantic comparison. Comparing with a struct won't give meaningful results. Structs that can be compared typically define a compare/2 function within their modules that can be used for semantic comparison.

That’s unexpected, please file a report!

Done: False positive type warning depending on a HEEX clause ordering · Issue #15370 · elixir-lang/elixir · GitHub

I think this warning was introduced with this version:

warning: use `or` instead of `||` for boolean checks
is_nil(id) || Enum.member?(deleted_ids, id)

I think this is not good. || wil short-circuit but or will evaluate the right-hand side.

If right-hand side is computationally intense, this is encouraging less performant code.

Weird, I think I always thought both short-circuited , but it seem neither do?

iex(1)> false or IO.puts("hi")
hi
:ok
iex(2)> false || IO.puts("hi")
hi
:ok

Requires only the left operand to be a boolean since it short-circuits.

Need to use true for short-circuit:

iex(1)> true or IO.puts("hi")
true
iex(2)> true || IO.puts("hi")
true

LOL… oh boy, uhhhh… who are you responding to? I never said anything!

They both seem to short circuit, though:

iex(3)> true or 0..100_000_000 |> Enum.map(& &1)
true
iex(4)> true || 0..100_000_000 |> Enum.map(& &1)
true

Both of those return instantly, in IEx, at least.

Am I just completely misunderstand what short circuiting is?

They do both indeed short-circuit, and the docs for both say they do. The difference is or requires the left side to be a boolean and it can be used in guards, while || does a “truthy” check of the left hand side and cannot be used in guards.