New EEP draft: Pinning operator ^ in patterns

[Wojtek Surowka]

> This change is completely backwards compatible in itself. Turning on warnings by default remains compatible with the code but not with many people's build systems, which is why that has to be done at a later stage (at least one major release later). This is the way many other changes have been made that have required that people make some edits to their code, such as the warnings for unused variables X unless you marked them with _X, the warnings for unused data structures such as {....} unless you write _ = {...}, the deprecation of erlang:get_stacktrace() in favour of using a variable for the trace in the catch clause, etc. Experience shows that this is mostly not a problem and is necessary in order to (slowly) evolve the language.

> Even when warnings would be on by default, you could still disable them to compile older codebases. The only incompatibility would be if they were eventually turned into hard errors - but that could only be done in a more distant future, *if and when* practically all existing Erlang code could be assumed to be using ^-annotations, which would only be the case if this becomes universally accepted as being a good thing.
 
Thank you for this clarification, I could have overreacted about this. The thing is that I worked in many environments with different technologies, and Erlang is by far the best one when it comes to "going out of the way" in the sense that I can focus on a real problem at hand, and the environment "just works". I value this aspect of the platform very much and this is why I reacted rather strongly.

Still another aspect of Erlang which is very valuable to me and many others is its simplicity. I like the way _Variables are done - their introduction did not impact simplicity of the core language, because it is just an additional convention. It is respected by the compiler, but only impacts warnings. From this perspective it is a completely optional feature. Pinning proposal is not like that, and in my mind is not worth the complication it introduces. However, a problem in discussions about simplicity is that arguments for it always sound too general. An argument for pinning can be made in a very specific way: here's a problem I had, and pinning makes it disappear. Arguments for the other side - we have something simple, let's not add to it - cannot be so specific. And there is a natural answer - yes it complicates but the change is very minor, the added complication is not significant.

Probably this is the reason why simple is less popular than complex, and in technology world we are overwhelmed with complexity, special cases, many ways to achieve the same goal etc. Such beauties as Erlang, with its radical simplicity, are rare. This is why I think we should be extremely careful about adding anything to this excellent language.

--
Wojtek Surowka