New EEP draft: Pinning operator ^ in patterns

[Richard Carlsson]

Den fre 22 jan. 2021 kl 12:49 skrev Svilen Ivanov <isvilen@REDACTED>:

> When I tried this on one of our projects with about 34000 lines of
> Erlang code in 140 modules, there was 180 +warn_unpinned_vars warnings.
> Vast majority - 160 of them in tests where matching was used as an
> assertion, and 20 in production code where matching of already bind
> variables was also used correctly.
> I suspect that the results will be similar for the rest of our
> projects.
>

First of all, thank you for actually testing it!

I just want to make it clear that the main purpose is not to find bugs in
existing code. It will always be the case that whatever idea you can come
up with to prevent bugs, you'll find relatively few occurrences in existing
code, if that code has been sufficiently exercised in production and/or by
test suites, because most of them will already have been found and fixed,
the hard way. The ones that still remain after that are those that will
only trigger under uncommon conditions (especially error handling code is
where such things may hide, because you often forget to test the error
cases properly). So yes, the results should be similar for most code bases
out there.

The main point of having a warning for (unintended) already-bound variables
is that you don't have to go the long way via 1) missing a vital point when
you read the code, 2) introducing a bug while editing the code, 3) running
the tests, 4) reading and understanding the mysterious and unexpected crash
report you got, and 5) staring at the code again until you understand what
went wrong, what the code was really doing, and what you have to do instead
to get your new change to work. If you're unlucky, your test suites don't
trigger the error and you'll get a bug report from a user instead, which
you'll have to fix later when you've forgotten the details already. But if
the compiler had told you about it right away, there would have been no
wasted time. And with an annotation or an explicit guard, you might not
have missed this detail in the algorithm to begin with.

        /Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210127/5e41bbe9/attachment.htm>