Elixir 1.19 inconsistent typing warning

[nwjlyons]

Elixir and Erlang/OTP versions

Erlang/OTP 27 [erts-15.1.2] [source] [64-bit] [smp:10:10] [ds:10:10:10] [async-threads:1] [jit]

Elixir 1.19.0-dev (b601b1c) (compiled with Erlang/OTP 27)

Operating system

mac

Current behavior

I know 1.19 is not released yet so feel free to close this ticket.

I only got this warning when running mix compile, not with elixirc. Both with 1.19-dev using asdf install elixir main-otp-27

git repo which shows the problem https://github.com/nwjlyons/foo/blob/main/lib/foo.ex

comparison with structs warning

["foo-#{i}": i > 0]

full compiler warning

  warning: comparison with structs found:

      i > 0

  given types:

      dynamic(
        %Date{} or %DateTime{} or %NaiveDateTime{} or %Time{} or %URI{} or %Version{} or
          %Version.Requirement{} or atom() or binary() or float() or integer() or list(term())
      ) > integer()

  where "i" was given the type:

      # type: dynamic(
        %Date{} or %DateTime{} or %NaiveDateTime{} or %Time{} or %URI{} or %Version{} or
          %Version.Requirement{} or atom() or binary() or float() or integer() or list(term())
      )
      # from: lib/foo.ex:3
      to_string(i)

  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.

  typing violation found at:
  │
3 │     ["foo-#{i}": i > 0]
  │                    ~
  │
  └─ lib/foo.ex:3:20: Foo.error/1

no warning for

if(i > 0, do: "foo-#{i}")

# or

if(i > 0, do: :"foo-#{i}")

Expected behavior

To be consistent with the if expressions. So consistently no warnings or all warnings.

[josevalim]

Thank you. We could address this warning but at the cost of preventing fewer bugs. For example, someone can pass a string or a decimal to this code, and it would return something, but that may not be valid. My suggestion then would be to explicit add a is_integer(i) guard and, since we will add type checking of guards in the next release, it should all just work. So I would say this will be closed as part of #13227 but you will need to change your code to make it more explicit.

[josevalim]

Closing as duplicate of #13227 for now. We may revisit to not emit this warning in the future.

[josevalim]

We got more reports, so we will tackle this.

[josevalim]

Closed by b27b911.