New EEP draft: Pinning operator ^ in patterns

[Frank Muller]

Fully agree with you Craig. Let’s keep this beautiful language simple.

And when in doubt, listen to Richard O’Keefe.

/Frank

Friday 15 jan 2021 03: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210115/ce31ff7b/attachment.htm>