New EEP draft: Pinning operator ^ in patterns

[Steve Strong]

Would it not be easiest to:

* Add the warning, but allow it to be turned off
* Add the operator / annotation

- Folk who like the existing state of the world can turn off the warning and move forward
- Folk who like the idea of a warning but prefer guards / assertions can enable the warning, fix their code and move forward
- Folk who like the idea of the operator can enable the warning, fix their code with the operator and move forward

Yes, you’ll find times when you look at someone else’s code and don’t like that the have / haven’t used the warning / used the operator, but there are numerous reasons why looking at some other code can be hard (coding style, parse transforms, even just a different style of whitespace to what your brain is used to parsing).

Maybe I’m just being simplistic, but it would be nice to move on...

> On 22 Jan 2021, at 15:16, Raimo Niskanen <raimo+erlang-questions@REDACTED> wrote:
> 
> On Fri, Jan 22, 2021 at 11:29:21AM -0000, Wojtek Surowka wrote:
>>> So I took the pinning branch for a spin and ran it against the Ra library (https://github.com/rabbitmq/ra/pull/209) I have worked a lot on the last few years. I found 2 bugs and at least a couple of places where I am not really sure about the intent of the match and where it could be done better. At some point I will run it against the RabbitMQ code. Who knows what I will find there! 
>> So thank you Richard, I take my hat (pun intended) off to you for this feature and for standing up for it against the onslaught of negativity around it. For me this feature, ad-hoc or not, addresses a real problem and will result in fewer bugs which makes me prepared to deal with any syntactic overhead it may carry.
>> 
>> This is once again argument for adding the warning, not for the new pinning operator. I think it was really smart move to connect the two, because many people may react in the same way: non-controversial part of the change helped me with my code, so the entire change is good.
> 
> I agree that a warning for binding in a pattern would solve the same
> problem.
> 
>> 
>> I do not think anyone here argued against the warning - provided it could be disabled by people who don't want it. The real discussion is about a potentially backward incompatible change in Erlang language. The syntax of this change does not look like anything else in the language, there is nothing similar, I think it can be safely said that it does not follow the conventions of Erlang syntax. Of course proponents of the change may say that conventions are not written in stone and can evolve, but I think it is important to be clear about it. I assume that the syntax is taken directly from Elixir, which is on syntactic level a very different language. Importing some random parts of Elixir syntax into Erlang won't turn Erlang into Elixir completely, but it will turn Erlang into worse language.
> 
> I can argue against such a warning, Richard already has.
> 
> I think it solves the same problem, but in a worse way.  Using the warning
> one would want to rewrite all pattern mathing with bindings into using
> guards instead, and that would be more code, repeating a variable,
> inventing a new variable.  All in all harder to read.
> 
> This is not importing some random part of Elixir's syntax.  This is adding
> a language feature that happens to be the same in Elixir.  And I think
> Erlang would be more readable with it and clearer because the intention of
> the code is more easily expressed.
> 
> I think the warning alternative would not make Erlang a better language.
> It would aid in enforcing a style that I think is clumsy and inelegant.
> 
>> 
>> I wonder if it is possible to split the proposal into warning part and operator part, so the intentions and results are clearer.
> 
> A warning for binding in a pattern maybe does not even need an EEP.
> 
>> 
>> -- 
>> Wojtek
>> 
> 
> -- 
> 
> / Raimo Niskanen, Erlang/OTP, Ericsson AB