The blog post gives the following example.
def example(x) when tuple_size(x) < 3
A subsequent call elem(x, 3) shall get caught by the type system.
Would this work in the following code?
i = 3
el = elem(x, i)
Or, would it fall back to a runtime check?
Thanks.
It will fallback to a runtime check! We may want to revisit this in the future and force elem to always be constant, and use elem! for runtime. Too early to say!
The detection of unused require is very nice!
There a a bunch of libraries out which are going to need a fix.
Namely require Logger.
And of course I got hit by that one too.
Just saying
I tried the RC1 at our codebase, and we had 3 classes of errors:
foo.bar when foo was dynamic(atom), easy fix by foo.bar().require.defp which implement liveview function components.For 1 I initially thought there was a bug in the type inference, as tests failed after changing it. Though I was just hit by a flaky test twice in a row 
2 really will clean up a lot and probably will even improve compilation times, as we break compiletime dependencies between modules. Half of the warnings is about Logger, though among the remaining half a good part is internal modules.
And with 3 I am wondering why those haven’t been recognized before. What I recognized was, was that the error spoke about “unused defoveridable”, which feels like leaking phoenix implementation details. I think the error message could be improved, though I am not sure how exactly. Among the samples I removed, there have been no false positives. Fixing all those warnings might get rid of a huge portion of frontend related code.
Sadly I will not be able to do more experiments than what I have already done before the actual release, and I am looking forward to it!
PS: compilation times remained stable
Just testing this out now - like everyone else the main warning I’m getting from my apps/libraries is about unused requires 
Though I’m also getting an error at the end of my test suite, after running mix test:
** (EXIT from #PID<0.94.0>) an exception was raised:
** (Protocol.UndefinedError) protocol Enumerable not implemented for :term (a struct)
Got value:
%{__struct__: :term}
(elixir 1.20.0-rc.1) lib/enum.ex:5: Enumerable.impl_for!/1
(elixir 1.20.0-rc.1) lib/enum.ex:184: Enumerable.reduce/3
(elixir 1.20.0-rc.1) lib/enum.ex:4672: Enum.reverse/1
(elixir 1.20.0-rc.1) lib/enum.ex:3919: Enum.to_list/1
(elixir 1.20.0-rc.1) lib/module/types/descr.ex:4194: Module.Types.Descr.map_literal_to_quoted/2
(elixir 1.20.0-rc.1) lib/enum.ex:1725: Enum."-map/2-lists^map/1-1-"/2
(elixir 1.20.0-rc.1) lib/enum.ex:1272: anonymous fn/3 in Enum.flat_map/2
(stdlib 7.2) maps.erl:894: :maps.fold_1/4
(elixir 1.20.0-rc.1) lib/enum.ex:2629: Enum.flat_map/2
(elixir 1.20.0-rc.1) lib/module/types/descr.ex:719: Module.Types.Descr.non_term_type_to_quoted/2
(elixir 1.20.0-rc.1) lib/module/types/apply.ex:1975: anonymous fn/2 in Module.Types.Apply.clause_args_to_quoted_string/3
(elixir 1.20.0-rc.1) lib/enum.ex:1725: Enum."-map/2-lists^map/1-1-"/2
(elixir 1.20.0-rc.1) lib/enum.ex:1725: Enum."-map/2-lists^map/1-1-"/2
(elixir 1.20.0-rc.1) lib/module/types/apply.ex:1975: Module.Types.Apply.clause_args_to_quoted_string/3
(elixir 1.20.0-rc.1) lib/module/types/apply.ex:1967: anonymous fn/4 in Module.Types.Apply.clauses_args_to_quoted_string/3
(elixir 1.20.0-rc.1) lib/enum.ex:5084: Enum.with_index_list/3
(elixir 1.20.0-rc.1) lib/module/types/apply.ex:1963: Module.Types.Apply.clauses_args_to_quoted_string/3
(elixir 1.20.0-rc.1) lib/module/types/apply.ex:1786: Module.Types.Apply.format_diagnostic/1
(elixir 1.20.0-rc.1) lib/module/parallel_checker.ex:338: anonymous fn/2 in Module.ParallelChecker.group_warnings/1
(elixir 1.20.0-rc.1) lib/enum.ex:2617: Enum."-reduce/3-lists^foldl/2-0-"/3
And no summary output is printed.
Tested with Elixir 1.20.0-rc.1-otp-28, Erlang 28.3.1 with the main branch of the GitHub - sevenseacat/cinder: A powerful, intelligent data collection component for Ash Framework resources in Phoenix LiveView · GitHub repo. It didn’t happen with Elixir 1.19.5-otp-28 (and same Erlang version)!
It’s extremely impressive how Elixir keeps getting faster and more powerful without breaking (almost any) backwards compatibility. Kudos to @josevalim and the team!
I got similar results (recompiled project + dependencies)
Project size (39_340 loc)
can you please give it a try too?cd lib
find . -name '*.ex' | xargs wc -l
> 39340 total
Dependencies (49)
cat mix.lock | wc -l
51 # first and last line are {} -> so 49 dependencies
Compile time script:
#!/bin/bash
# clean the current build directory
rm -fr ./_build/dev
SECONDS=0
mix compile
duration=$SECONDS
echo "$((duration / 60)) minutes and $((duration % 60)) seconds elapsed."
Results:
elixir 1.19.5-otp-27
erlang 27.3
1 minutes and 50 seconds elapsed.
elixir 1.19.5-otp-28
erlang 28.3
1 minutes and 53 seconds elapsed.
elixir 1.20.0-rc.1-otp-28
erlang 28.3
1 minutes and 48 seconds elapsed.