There have been some concerns regarding the loss of precision in warnings, which is an excellent concern. I will address them altogether instead of individually.
We are not proposing to remove all long warnings and all long errors. Rather, this is a mechanism that would allow them to do so, if desired and if relevant.
@Eiji mentioned an excellent example: function clause errors. Those errors are long, and they will continue to be long, because everything they show is contextual information. @blatyo brought another good example. Both of those cases should continue as is. The help catalog is useful to store complementary and non-contextual information about warnings and errors. All contextual information should remain as part of the warning/error.
===
The other concern that seems to be common is about emitting detailed (long) warnings by default. This seems like a good idea based on the warnings we have today but I would like to remind everyone that, once the catalog exists, it is very likely that many warnings will provide a detailed variant.
For example, “unused variable x” may now have one or two paragraphs about prepending an underscore to the variable name. Similarly, when you use a non-guard function in a guard, I would like the detailed information to show all available guards. Therefore, if we are detailed by default, we may end-up showing a lot more information than we do today. For those reasons, I think detailed by default is practical today, but not when the catalog will be place.
I would like to flip the question. Instead of discussing if we should have “shorter vs long” by default, what can we do to make sure that a newcomer will understand what elixir -h elixir:foobar in a warning/error means and make sure that they will be able to access the detailed information?
