New EEP draft: Pinning operator ^ in patterns
Mon Jan 18 10:59:56 CET 2021
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?
> 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
> 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(),
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 Boudeville
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
More information about the erlang-questions