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.
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!):
But I can sympathize with your argument about readibility.
Dialyzer types are not dependent ones, but the fact that you can specify an explicit set of return values without bothering with creating complete new types and conversion routines from that types into ordinary numbers (just as an example).
I do not think there has. The main disadvantage of moving specs to a different file is that it is very easy to forget them (and then they for instance are not updated when the functions themselves are changed).
In a language that performs full compile-time type checking it is enforced that the types and the actual signatures match, but in Elixir this is not the case.