The black of trust is a great way of putting and describes my same feeling. I noticed also when switching between Ruby/Elixir to Swift. Making sweeping rename changes is trivial with types.
gshaw
Plasmablitz
Will the type system be able to create the following function type for, for example, the Enum.map function?
%(Enumerable(a), (a -> b)) -> (list(b))
That we relate the input and output types of a function?
So that we have, for example
[1,2,3] |> Enum.map(&to_string/1) |> Enum.sum
with a type error warning, that Enum.sum expects an enumerable with numbers as type, but it receives a list of strings?
But I’m very curious to see how it all plays out 
josevalim
Creator of Elixir
apoorv-2204
stevensonmt
Ultimately Elixir is still going to compile to BEAM byte code, right? So in runtime the type system should not affect message passing at all. The type system will simply include extra work in the compilation step. I don’t know the specifics of how the core dev team is going to handle it, but the simplest answer would be that the type system (at least as outlined in the paper linked in the announcement) will include a dynamic() type, so anything that absolutely needs to remain dynamic could just be that type.
AndrewDryga
Maybe instead of adding case! we can always yell when something is not matched and have people that want the type system update code to something like:
case foo() do
:foo -> :foo
:bar -> :bar
other -> raise CaseClauseMatchError, other
end
If the desirable default is to not raise then the case macro can add that last clause by default (or via a compiler flag).
This way the code will be more explicit without the need to always think “do I want to raise here or not?” as you write it. For me personally, I want to always get a warning that there is a new unmatched return and I try to have my with and case blocks reasonably explicit for the people that will maintain the code I wrote.
josevalim
Creator of Elixir
Well, that’s what case! will do in a nutshell, the question is if it is worth adding specific version to encapsulate this pattern or not. I would say that asking folks to raise a magical raise CaseClauseMatchError is not a very ergonomic API, although they could also just raise "unexpected clause".
Elixir generally avoids global configuration for compilation (or in general), because it causes all sorts of problems. Moving code between projects can now behave differently. When somebody does a bug report, we need to ask them if they set compiler flags. And then we have consider macros: this will lead to scenarios like Phoenix and Ecto have to compile code to handle both versions of the code. Etc, etc.
josevalim
Creator of Elixir
One alternative we can consider is to introduce something like Scala’s ??? to signify “I was not expected to reach here”. This can be used to denote functions to be implemented, clauses that are meant to unreached, etc. Perhaps a bit clearer than case! and it could even be used in other occasions:
case some_fun(...) do
{:ok, ...} -> some_code(...)
:cached -> ???
{:error, ...} -> more_code(...)
end
This allows you to match on all patterns but say some specific patterns are never meant to be reached. It may have the best of both words: you can choose to match on patterns or not and you can choose to expect some patterns or not.
11
dorgan
This truly matches the “It reads like natural language” considering a normal conversation goes like:
-This should never return this value
-But it did return this value
-???