New EEP draft: Pinning operator ^ in patterns

[Richard Carlsson]

Den tis 19 jan. 2021 kl 12:48 skrev Wojtek Surowka <wojteksurowka@REDACTED>:

> The most problematic part for me is that the proposed change
> is not backward compatible. I saw arguments that it will impact only small
> percentage of the code and the code will be easy to fix. I understand that
> Erlang is used in different contexts, and in some of them it sounds an easy
> thing to do. But if a system uses several third party
> applications/libraries
> managed automatically by rebar3 the problem is much worse. A
> backward-incompatible change would mean that the an upgrade makes my system
> not working anymore, and I do not have an immediate and good way of fixing
> it, if incompatibility is not in the code I have under direct control.
>

This change is completely backwards compatible in itself. Turning on
warnings by default remains compatible with the code but not with many
people's build systems, which is why that has to be done at a later stage
(at least one major release later). This is the way many other changes have
been made that have required that people make some edits to their code,
such as the warnings for unused variables X unless you marked them with _X,
the warnings for unused data structures such as {....} unless you write _ =
{...}, the deprecation of erlang:get_stacktrace() in favour of using a
variable for the trace in the catch clause, etc. Experience shows that this
is mostly not a problem and is necessary in order to (slowly) evolve the
language.

Even when warnings would be on by default, you could still disable them to
compile older codebases. The only incompatibility would be if they were
eventually turned into hard errors - but that could only be done in a more
distant future, *if and when* practically all existing Erlang code could be
assumed to be using ^-annotations, which would only be the case if this
becomes universally accepted as being a good thing.

        /Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210119/974e9b88/attachment.htm>