New EEP draft: Pinning operator ^ in patterns

[Loïc Hoguin]

On 21/01/2021 20:55, Richard Carlsson wrote:
> Den tors 21 jan. 2021 kl 18:21 skrev Nicolas Martyanoff 
> <khaelin@REDACTED <mailto:khaelin@REDACTED>>:
> 
>     While I agree that some of the examples you give are indeed
>     confusing, why
>     would a warning flag not be good enough ? It would have multiple
>     advantages:
> 
>     - Anyone would be able to either warn or totally reject (with
>        warnings_as_errors) these kinds of construction.
>     - Anyone who does not care would be able to totally ignore it (and
>     please do
>        not tell me that this new operator/annotation would be optional,
>     there is no
>        way it would not be become mandatory at some point).
>     - This would have no effect on existing codebases, therefore
>     removing any
>        migration cost. I cannot even begin to explain how bad of an idea
>     it would
>        be to force every Erlang developer all other the world to patch
>     all their
>        projects because something that worked perfectly before now
>     requires a
>        cryptic annotation.
> 
> 
> As you yourself note, the warning is likely to eventually be made the 
> default (if generally accepted), and this means for most code bases 
> these days that they'll be patching their code anyway, just in order to 
> compile cleanly with default flags - something most projects want.

If the warning gets enabled by default I think I would just disable the 
warning in my own projects. I agree that ^ can make some code more 
obvious, but I definitely don't want this to be enforced everywhere. 
Socket messages, monitors and other message refs, tests and other 
similar places would not gain in readability in my opinion. The places 
where readability increases are those where matching is not expected, 
like most of your examples seem to be. Though in some of those cases a 
comment would be much better.

You say ^ indicates that the match is intentional, and in a perfect 
world perhaps that's true, but in the real world you'll also end up with 
misplaced ^ that should not be matches at all, as some of your examples 
show. So while you do increase the confidence that the match was 
intended, it's not necessarily the case. Ultimately all it says is "this 
variable is already bound".

As a result, the ^ alone does not convey much information. You don't 
know why the dets:check_file_header/2 function is called twice, a 
comment would work out much better. (A comment explaining why one call 
is protected in a try..catch and one isn't would be great as well.) 
Maybe parse_term/3 really does have to return the same "D" value, but ^ 
only tells you it's expecting the same value, it doesn't tell you why. 
And so on.

There are a few good catches, but this only comforts me into thinking 
this belongs more in tooling than in the language. That said, the 
warning could be used as a tool on its own, just making a special 
non-test build would print all the warnings which can be quickly 
checked, similar to +bin_opt_info. Maybe enable it on a per module basis.

-- 
Loïc Hoguin
https://ninenines.eu