I had to create an account here just to say how much I love this. This is incredibly exciting!
lifeofdan
munksgaard
Just want to add to the chorus here, I am very excited by this.
As someone fairly new to the Elixir community, is there any way for me to contribute to this work? I have limited free time, but I’d love to help out with whatever I can.
2
josevalim
Creator of Elixir
The type system allows us to support any literal as type but it is still undecided if we want to do that. Opposite to the Dialyzer, an actual type system will be strict about the expected arguments. Imagine this code:
$ :foo or :bar -> string
def foo_or_bar(:foo), do: ...
def foo_or_bar(:bar), do: ...
Now imagine you call it like this:
foo_or_bar(String.to_existing_atom(string))
Because you are passing any atom to the function, the type system will warn about a type error. While Dialyzer would never warn. So you would need to write this instead:
case String.to_existing_atom(string) do
:foo -> foo_or_bar(:foo)
:bar -> foo_or_bar(:bar)
_ -> raise "expected foo or bar"
end
Therefore, more specific types will require you to prove that you are passing those specific types and that may actually make the type system more annoying than helpful.
Since there are trade-offs here, it is a decision we will make later once we have a better feeling for the type system.
Correct.
21
dmitriid
I foresee the problem where code will need to be annotated with both (at least for a while). And where people would be loathe to convert their typespecs to the new syntax.
While there are no user-facing changes yet, this is something to consider.
Another minor, personal gripe I’ve always had with typespecs: they are outside the function, and you need to update code in two places when you changed something. I’d love for the specs to be inline, but then no idea how to deal with functions with multiple definitions 
1
josevalim
Creator of Elixir
I am afraid there isn’t much we can do. Using typespecs for the type system will definitely be harmful in the long term, as types won’t be as precise as they could be. Our suggestion will be to rewrite the typespecs as you convert, especially because they are not used to drive Dialyzer’s inference (their benefit comes from documentation/specification, which you will get from the new type system as well).
I actually think this is harmful as it couples the types with the implementation and you can accidentally change the signature as you refactor a function from one ↔ many clauses. Also, we already have pattern matching and default arguments in signatures. Adding type declarations to the mix will allow our function signatures to become really really large and somewhat unreadable.
13
Sorc96
I’ve been wondering how you were going to approach this. I don’t think it’s just a problem with literals, though. This pattern where we restrict the input with a pattern match and pass in values that cannot be proven to be correct seems very common. And if an invalid value gets passed due to a bug, that seems to work well with the “let it crash” approach.
I’m not sure if there’s a way to make these two approaches work together. Maybe it would require changing the call site to say “Trust me, this value will be valid” and then the type checker would basically fall back to the optimistic Dialyzer style where it would only check that it is possible for the value to be valid.
Anyway, I’m sure you’ve spent much more time thinking about this, so I’m pretty excited about whatever you end up doing 
3
cevado
Would it be a warning that can be ignored or an error?
I like the idea of using types as documentation, but it’s extremely annoying to document functions that expect a map with specific string keys.
Could it be parametrized? I know it’s difficult to take that decision now, but just as the formatter, some stuff initially was not supported but in later versions more configuration was added to the process. maybe something that we can set as compiler options in mix.exs 
2
josevalim
Creator of Elixir
You are correct. My worry (which may or may not be unfounded) is that literals would accentuate the problem and require additional functions. For example, if we break integers into pos_integer or zero or neg_integer, we may need to add convenience functions such as String.to_positive_integer to make sure we propagate more type information. With atoms, that’s a smaller concern, because dynamic creation of atoms is more uncommon.
Something else to decide, as you described, is what happens when you, on purpose, want to ignore a return type of a function. :ok = some_fun() where some_fun() also returns {:error, _}. Is that a type error or not? What about case some_fun() do but you match only on some of the possible return types?
We could ignore by default, but then it means that if you matched on all results of some_fun() and then some_fun() adds a new return type, a type error could leak through the system. In this scenario, we may need to introduce functions such as case! which means: “we may raise at runtime for unmatched clauses because we are not forcing you to check them all”.
So we talked a lot about those cases and part of the adoption challenge will be in figuring out how frequently those happen and what mechanisms we will have around them.
A warning but most likely non-ignorable.
It may be that you will need to cast your string keys into atom keys and then rely on atom keys through the system. This is pretty much similar to all other typed languages: you need to cast the data into your types as it enters the system.
It is too early too say but we most likely won’t add any sort of configuration around this, otherwise will generate incompatibility between projects (some will be more precise than others and that can be a recipe for disaster).
13
cevado
I don’t like this approach of casting data too early in the system, at least in my experience it drive to unnecessarily rigid systems.
I was expecting to be able to express something like:
$ %{"foo" => string, "bar" => integer} -> success()
$ map -> error()
So i could be strict on success and loose on failures.
1
dimitarvp
We already have Dialyzer and it’s more lax, no need to duplicate that behaviour IMO.
Let’s have the new type system be more strict. It would also be a good step towards exhaustive pattern matching. Whoever does not want “annoyance” will simply not use the new system.
Though if it will replace the current type specs then I see your point.
10