2 Likes
Seems like an update that things are moving along well. Exciting! 
6 Likes
@josevalim please don’t tell me that what @wojtekmach is saying in the reply to a comment (here: Wojtek Mach (@wojtekmach): "if you mean something like: def f(x :: MapSet.t) then that’s a no. It’s a few steps until explicit type syntax appears still though." | nitter) is the actual plan.
If it’s truly the plan to make function headers as unreadable as in C++ or as verbose as in Java I can’t overstate just how bad that’s going to be.
For God sake, PLEASE (with a cherry and sugar on top) keep the typing separate from the function header.
TIA
PS. When in doubt just consider this:
- Elxiir benefits plenty from its readability-minimalism (you should know - you created it)
- Any benefit from its typing is questionable and sacrificing the former at the altar of the latter would be such a shame
3 Likes
This is binary pattern matching syntax. And already exists in elixir if you match out a certain number of bytes in a pattern.
The syntax for functions will be like
$ integer() → integer()
def func(num) when is_integer(num) do
…
Afiak
2 Likes
I understand it’s a binary pattern matching syntax, but please read the Jose’s colleague reply that I linked above.
This line is what I’m referring to:
“It’s a few steps until explicit type syntax appears still though.”
What I am afraid of this means is:
“It’s a few steps until we make it look like C++.”
Wojtek says “no” to that syntax in that reply. I’m not José but nothing he has said suggested we’re going to get that, that would be kind of insane coupled with pattern matching (and I’m with you, I hate it). We should be getting something like what @ONeill just posted.
3 Likes
Yeah, he says that f(myset :: MapSet.t) is not what they are thinking but the final syntax isn’t finalised.
However from streams and talks that have been given on this topic they seem to be in favour of the $ syntax, though obviously things can change as community feedback rolls in
Yep, at first glance I was also like WTF is that but then realized it’s pattern matching in a binary. Probably not the best example choice by Jose, looks like 
if you don’t know what it does.
1 Like
Yeah I did a double take at first 
I guess it’s just the first part to be implemented, they are doing it gradually
1 Like
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 Likes
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 Like
I most certainly hope I misunderstood it.
Happy to hear that (re the uproar)
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.
34 Likes
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 Likes
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.
16 Likes
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 Likes
