New EEP draft: Pinning operator ^ in patterns

[andrei zavada]

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 <zxq9@REDACTED> 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