You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We already deprecate _ as a variable name. Hopefully, we can eventually use it as a placeholder for discarded lhs values (#9343) and/or for a compact anonymous-function/currying syntax (e.g. _.a for x -> x.a: #554, #5571, #22710).
As I discussed with @Keno today, it might be good to additionally deprecate all variable names consisting only of underscores, e.g. __ or ___. It is weird to disallow _ but allow __, and multiple underscores might be useful for something later.
(One possible use: in an implicit currying syntax, make f(g(_,y)) denote f(x -> g(x,y)) and f(g(__,x) denote x -> f(g(x,y)), i.e. _ is "tight" and __ is "loose".)
The text was updated successfully, but these errors were encountered:
We already deprecate
_
as a variable name. Hopefully, we can eventually use it as a placeholder for discarded lhs values (#9343) and/or for a compact anonymous-function/currying syntax (e.g._.a
forx -> x.a
: #554, #5571, #22710).As I discussed with @Keno today, it might be good to additionally deprecate all variable names consisting only of underscores, e.g.
__
or___
. It is weird to disallow_
but allow__
, and multiple underscores might be useful for something later.(One possible use: in an implicit currying syntax, make
f(g(_,y))
denotef(x -> g(x,y))
andf(g(__,x)
denotex -> f(g(x,y))
, i.e._
is "tight" and__
is "loose".)The text was updated successfully, but these errors were encountered: