Re: New EEP draft: Pinning operator ^ in patterns

Here's my tiny but clear vote against the pinning operator. I'm not
going to rephrase all the arguments that have already been laid out by
those with bigger voices, which I wholeheartedly support.

On Fri, 15 Jan 2021 at 04:27, zxq9 <[email protected]> wrote:
>
> On 2021/01/15 0:41, Raimo Niskanen wrote:
> > On Thu, Jan 14, 2021 at 02:13:47PM +0100, Richard Carlsson wrote:
> >> The way I planned it is:
> >>    1. Even from the start, pinning will always be allowed, without requiring
> >> any flag to opt in. This does not tell you about existing uses of
> >> already-bound variables, but you can start using pinning right away for
> >> readability and for avoiding bugs when refactoring. The compiler will
> >> always tell you if a pinned variable doesn't exist, so you don't
> >> accidentally accept any value in that position.
> >
> > I do not like an intermediate state where pinning may be used in only some
> > places in a module.  Code should be rewritten module wise to keep each
> > module consistent.  And if a module is using pinning it should be a
> > syntactical error to not use pinning where it should be.
>
> lolwut?
> Let's just be clear on this:
> The proposed "compromise" to not making the language more complicated
> and inconsistent is to only make it complicated and inconsistent
> optionally a module at a time?
>
> No.
>
> Erlang is valuable because it lacks glyphy nonsense like this. As ROK
> and others pointed out we already have a compiler warning for masking
> and are free to invent whatever arbitrary label we want in a lambda. So
> what imagined problem is this supposed to be solving?
>
> "If it ain't broke, pretend it is broken until your solution looks
> marketable."
>
> If you want to use Elixir, just use Elixir.
>
> We really don't need an `-import(useless_nonsense).` pragma.
>
> -Craig