Second this.
mau013
joddm
tozz
Awesome release, so many great things happening in the ecosystem 
I am curious as how to solve the following warning that is generated now though;
In my config.exs I have this simple line config :app, :environment, config_env() which I then use in modules @env Application.compile_env(:app, :environment).
That “breaks” in this code though.
defp some_function(mail, subject) do
mail
|> subject(
case @env do
:dev -> "[DEV] #{subject}"
:stage -> "[STAGE] #{subject}"
_ -> subject
end
)
end
warning: the following clause will never match:
:stage
This both correct and wrong.
It’s correct in the context of the running process, but wrong in general, as it will be :stage in another environment. We still can’t type module attributes right? Maybe this is an anti-pattern altogether?
1
michallepicki
Seeing similar warnings when using compile-time config for stubbing an external service module, and the stub doesn’t return error tuples in dev Mix env, but the error handling code is needed for test and prod Mix envs. It’s pretty cool to see the compiler being clever enough to detect this. But it would be nice to have a proper way to communicate to the compiler that the code is not dead code and it’s needed for different Mix env or config values.
1
cmo
You could move the compile time code outside of the function.
case @env do
:dev -> defp prepend_env_to_subject(subject), do: "[DEV] #{subject}"
:stage -> ...
_ -> ...
end
defp some_function(mail, subject) do
subject = prepend_env_to_subject(subject)
subject(mail, subject)
end
2
ken-kost
Curious why Tuple.append is deprecated. 
I updated elixir and got a warning in my AOC solution for it. I was building a tuple in reduce and appending element at the end. Now I Tuple.insert_at(acc, tuple_size(acc), element). Would that be an idiomatic replacement?
0
lud
You can use :erlang.append_element(tuple, value) to skip the Elixir wrapper. It does not seem to be scheduled for deprecation in OTP 28 or 29.
Now the Elixir commit that added the deprecation seems to be related with types, so I guess you will not benefit from them if you do that.
So I would use tuple_size/1. Honestly I have never needed to append to a tuple anyway 
And thank you to the team! Great achievements this year \o/.
1
tozz
arrowsmith
Congrats on the new release! I’m really excited to get using it.
But I have a question about the new :auto_reload IEx option.
I see that, with this new option enabled, IEx now automatically picks up any changes to my code when it gets recompiled. But the code still doesn’t get recompiled automatically. I have to e.g. do mix compile in another terminal window, then the newly-compiled version will be available in IEx.
But this isn’t really an improvement over just typing recompile() within IEx itself. Is there some way to watch the files and auto-recompile them when they change, so I don’t have to make the manual recompilation step at all?
I know that Phoenix recompiles code in dev mode with Plug.CodeReloader, but this only happens on the next request, i.e. not at the actual point when the files change. So I’d still have to have my Phoenix server running, then go and e.g. refresh a page in the browser after changing code before the changes will be available in IEx. That’s not a good workflow if I want to only be flipping between IEx and my editor.
Is there an easier way to use auto_reload: true? Am I misunderstanding anything?
1
