yeah and @DaAnalyst you need to chill a bit. Jose is smart, he knows what he’s doing.
hubertlepicki
zachallaun
I think you’re misunderstanding Wojtek’s message. Let’s be explicit:
This is not planned:
def some_function(arg :: MyStruct.t()) :: return_type() do
...
end
Something like this is planned, but the syntax is not finalized:
$ MyStruct.t() -> return_type()
def some_function(arg) do
...
end
5
sodapopcan
Again, I’m not José, but I’m sure you did 
I think there would be a lot more uproar 'round here if that was on the table.
1
DaAnalyst
DaAnalyst
josevalim
Creator of Elixir
You misread his reply but keep in mind this is not a good way to approach the discussion. We will definitely make mistakes as we implement the type system and I hope the feedback will be more constructive than the above.
Engage constructively. If you think it is bad, just don’t say it, argue your case with examples. Provide context and propose alternatives if possible.
37
Fl4m3Ph03n1x
Congratulations on the development!
And for the record, I will be a very happy Elixir coder if this new syntax is similar to C or Java typing (having types on function headers).
I understand some people will not agree with me. That’s fine.
I also understand other people will agree with me. That’s also fine.
If I get this correctly, being the nature of gradual typing systems, I assume these signatures will not be mandatory in every function. If this is the case, then I believe this greatly benefits elixir:
- if you like static typing syntax ala Java, you can use it
- if you don’t like typing at all, you can avoid it
This direction will eventually make both parties happy. A win-win scenario if I ever saw one.
And while I am admittedly biased towards having a strong typing system, I still want to publicly state that I (and my team) have great expectations in regards to this system and eagerly await your next move/news on it.
5
josevalim
Creator of Elixir
Thank you @Fl4m3Ph03n1x!
To align everyone’s expectations, our goal is to perform inference of all patterns and guards by Elixir v1.17, as outlined here: Type system updates: moving from research into development - The Elixir programming language
There are still no typing syntax or changes to the language. And there is still a chance we won’t go forward with this. But this is a very exciting step for sure.
17
baldwindavid
A lack of static types is the only thing in Elixir that I have longed for. Really just compile-time checks on the existing typespecs are all I needed, but this system is much more powerful. I’m excited about any potential additions. To me, if this all becomes viable enough to get to the point of debating syntax we’re in a really good spot as we will have passed the first two milestones layed out in Type system updates: moving from research into development - The Elixir programming language.
Thanks for all the work on this. Five years in and I’ve never loved this language more.
5
sodapopcan
Personal preferences aside, the problem I see with types in the function head is you end up with this:
def login(%User{admin: true} = user :: User.t()), do: ...
which is a bit much. Sure you can argue you could write this:
def login(%{admin: true} = user :: User.t()), do: ...
but that breaks the spirit of not changing the nature of the language. Besides, %User{} = user is essentially having the type in the function head and now we’re (maybe) going to have that codified into compile time!
6