It would make using pattern matching very cumbersome and the patterns would quickly become unreadable if they were to include type information.

Types and specs in Elixir are not even used at compiletime, except that they get integrated into the compiled modules.

Then the can get evaluated using a tool called dialyzer, which is from the erlang/beam toolchain and not related to elixir (directly).

Since elixirc does not resolve types, but only stores the information of them into the module, it would telling some false story when they are inlined. As it is now, it is more or less obvious that they are an optional extra.

Also elixirs (and erlangs) type annotations are in a way powerfull that I can’t relly think a way of to express it inline while maintaining readability.

Consider this one (this is a single type and not 4!):

@spec foo(:error) :: 1
@spec foo(:two) :: "two"
@spec foo(integer) :: String.t
@spec foo(list(integer)) :: integer

Or the more classical ones;

@spec map(list(a), fun((a) -> b)) :: list(b) where a: var, b: var
@spec fold(list(a), b, fun((a, b) -> b) :: b where a: var, b: var

These specs are from the deepest areas of my mind, maybe I confused a bit syntax of them with erlang, but roughly they should show what I mean.

There are even specs much more complex you have to think about, just take a look at the contracts for all the GenServer like behaviours…

Typespecs in the form currently used in Elixir are not adding anything new to the language, nothing at all. They are using already existing feature of module attributes, i..e. the stuff you use with @ sign.

You can always add new syntax to the language itself, but if you do so it’s harder to remove it afterwards. Typespecs are now just data, and are treated as such, if they are ignored or changed altogether your programs will not break at all because they do not really affect your runtime.

I appreciate Elixir creator(s) keeping the language (fairly) small. Smaller is better.