New EEP draft: Pinning operator ^ in patterns

[Raimo Niskanen]

On Fri, Jan 15, 2021 at 07:35:06PM +0100, Olivier Boudeville wrote:
> Le 1/15/21 à 4:35 PM, Raimo Niskanen a écrit :
> > 1) Would the language be a better language with a mandatory pinning operator?
> 
> Hi,
> 
> Thanks Raimo for this interesting EEP. As for me, I could do without 
> pinning. Would such a feature impact the AST?

It is Richard Carlsonn's EEP.

I just find some merit in it and think it gets bashed in an unconstructive
way on lists and pull request.

> 
> On a related "hazardous matching" topic, there is an Erlang "language 
> feature" that could (IMHO) be removed for the best, hopefully with no 
> issue in terms of backward-compatibility: the infamous matching of muted 
> variables. I am a big fan of commenting thanks to a muted variable the 
> intent related to an argument, like in:
> 
>     send_safe(_DefaultTimeout=1000, _AttemptCount=5, ...),
> 
> ...but of course such bindings will collide with any other, potentially 
> unrelated _DefaultTimeout or _AttemptCount bindings in the same scope, 
> resulting in "surprise-matches" that could be spared to the unwary 
> developer.
> 
> Couldn't we stop matching these muted variables, knowing that their 
> management is already special-cased in some contexts? (for example they 
> do not trigger unused warnings; "_" is never bound either). No sane 
> existing code should rely on this kind of match anyway, isn't it? Or is 
> there a use-case I overlooked? If the semantics of muting is "don't care 
> about the value", isn't it more surprising that they match rather than 
> they do not?

I am sure that you are aware of the fact that it is only the _ variable
that is anonymous and different for every occurence.

The _Variables with a leading _ are normal variables, but a compiler
warning for not using them is muted.

There is a use case I have seen that you may have overlooked:

    _X = foo(),
    ?debug_print(_X),

where depending on a compile time definition ?debug_print/1 may not use _X
at all.  Anyway, it is mainly some kinds of debug code, also simply
commenting out an io:format, but being to lazy to remove a variable.

Jose Valim has suggested a warning for repeated occurences of underscored
variables, since as you (and he) say(s), it is almost always accidental.

It may be a win to loose the debug use case above.


> 
> Best regards,
> 
> Olivier.
> 
> -- 
> 
> Olivier Boudeville

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB