See the post: https://elixir-lang.org/blog/2017/12/05/whats-new-in-elixir/
Kudos to @doomspork for starting the series!
20 Likes
Gives me 404 
It’s the trailing / on the link
1 Like
The link works fine here. Maybe it is something related to the CDN? Please try again soon!
1 Like
Working fine here too 
Well done @doomspork - I am sure people are going to look forward to these updates 
3 Likes
In the last bullet, I believe “Steam” should be “Stream.”
4 Likes
@josevalim: Link url in HTML code on this page:
<a href="github.com/whatyouhide/stream_data">stream_data library</a>
Is interpreted in my browser as:
https://elixir-lang.org/blog/2017/12/05/whats-new-in-elixir/github.com/whatyouhide/stream_data
My browser: Vivaldi 1.14.1030.3 (latest snapshot) 64-bit
Where could I submit a bug and PR? 
Elixir is one of projects that I’m always waiting for next version. 
2 Likes
Disagreements about formatting are a thing of the past!
They aren’t as we still have the choice to not use the formatter.
I keep my stance, that shuffling comments (eg. comments on struct fields) and removing trailing commas is a bad idea. Also I’m not a friend of the uniform gap of a single line between different clauses of the same function and totally different functions.
Stream data and property testing will be joining Elixir core in a future release.
I’m looking forward into this!
3 Likes
I think it’s implied that this is only when actually using the formatter.
1 Like
Same here. I much prefer writing code like this:
defmodule X do
def a(param1, param2 \\ nil)
def a(param1, nil), do: ...
def a(param2, param2), do: ...
def b(whatever), do: ...
end
When scanning the code, this gives me an immediate clue that these 3 functions above are function header and two pattern-matched variants.
As @ericmj said, we’re not mandated to use the formatter of course, but I’d still expect the above to be the default.
1 Like
Great that the dynamic supervisor sneaked in there. I was trying to implement one a month or so ago, and happened on the discussion on the Elixir repo from a year or so ago when the idea was floated, just assumed it had come to nothing and been shelved, it’ll be really useful to have that out of the box.
1 Like
I have fixed it. But a PR is definitely appreciated in the future, the repo is at GitHub - elixir-lang/elixir-lang.github.com: Website for Elixir.
Please open up an issue about the comment shuffling on struct fields, I don’t believe this particular behaviour is desired. The other complaints had their pros and cons discussed elsewhere, so I won’t rehash them there.
Ironically the code you wrote would be kept as is by the formatter. The issue is with do/end blocks which is where most disagree in regards to the placement of newlines (and the formatter chose to add a newline before and after the block).
3 Likes
The comment shuffling has been discussed as well and seems to be as expected. Also I am aware of the discussion, but it did not convince me.
Especially as some things are explained with less diff-noise, but trailing commas are removed, which causes additional noise…
I do not want to restart the discussion though, I just wanted to point out, that the question about formatting is not answered yet.
mix format is to inflexible.
2 Likes
Surely the point is to be as inflexible as possible: after a period of time using a formatter, you simply stop noticing the differences between the format it applies and what you previously did, it just becomes “what Elixir code looks like”
2 Likes
But especially the comment thing is a showstopper for me. I will never accept this as the way elixir is looking like or should look like.
I want to comment a field, so I want to have the comment besides the field, and not 3 lines up, mixed with all the other comments.
2 Likes
Ah, playing around with it now and I see what you mean, that is quite annoying. Looks quite tricky to generalise rules around that from a cursory glance over the formatter code 
1 Like
You probably have noticed that our stance with the formatter is to be as rigid as possible and then add more flexibility based on demand. Since that initial issue, we have made the comment handling more flexible, to the point there is no reason to not handle it inside structs. Thanks for pointing it out though, I will reopen that existing one.
That’s the pro of trailing commas… unfortunately it comes with cons too, mostly due to optional parens. I am sure we discussed it here but I can’t quite find the link right now. Help?
Yes!!!
1 Like
Oh, it already preserves them inside structs in master (from when we made it more flexible).
2 Likes
At the places where we have a demand for trailing commas, there are no optional parens. We already have used either square brackets for a list or use curlies for a map/struct.
We are not yet at the point where we talk about trailing commas in multiline function calls (which we need to allow at the compiler first and even worse are partially allowed)
2 Likes
That’s not true. See keyword lists without brackets inside function calls.
1 Like
See keyword lists without brackets inside function calls.
I said, we are not at the point to discuss those yet, as the compiler currently does not support trailing commas in function calls and those from the bracket-less-KW-lists do only work by accident.
1 Like
