New EEP draft: Pinning operator ^ in patterns

[Raimo Niskanen]

On Mon, Jan 18, 2021 at 11:09:06AM +0100, Loïc Hoguin wrote:
> On 18/01/2021 10:59, Raimo Niskanen wrote:
> > On Fri, Jan 15, 2021 at 07:35:06PM +0100, Olivier Boudeville wrote:
: ::
> >>
> >> 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.
> 
> As long as it's optional. It's the kind of scenario where I definitely 
> want to avoid using _X variables for normal builds, but want to keep 
> using _X variables during test builds for debug purposes. In that case 
> it's more a convenience than anything admittedly.

For us working in large corporations that have coding policies; optional
warnings are not optional in practice.  The current trend is towards
activating all warnings and using warnings as errors, in the name of
improving code quality.

So if there would be introduced an optional warning for double use of
underscore variables, I would be forced to remove all such uses.  At least
one day in a not too distant future.

When that happens I and other programmers will find some way to have debug
printouts.  It feels solvable.

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

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB