New EEP draft: Pinning operator ^ in patterns

[José Valim]

> it has literally zero cost, because it is OPTIONAL.

Optional features have a cost too because different teams, different
organizations, different projects, end-up opting in to different subsets of
the language and now there are additional context switches whenever you are
swapping codebases. Be it inside large organizations, throughout the
community, etc.

Inside a team/organization, we expect to have some standardization but
sometimes it doesn't happen or it happens too late, and that compounds. So
while it can be mitigated, there is definitely a cost.

And there is also the learning cost, the cost of the docs, and even the
cost of using an operator. What if in 5 years someone comes up with a great
use case for the ^ operator? Well, unfortunately it would be taken by an
optional feature...

On Fri, Jan 15, 2021 at 1:42 PM Eugene <e@REDACTED> wrote:

> > This is a cute feature, but it carries
> > a large cognitive cost and is not worth having compared to how
> > relatively little it is used.
>
> it has literally zero cost, because it is OPTIONAL.
> you want "old" behaviour you simply omit new feature.
>
> in return, if you read a program and see this new notation
> you immediately (without reading context) know that at this
> certain mention this particular variable is UNbound or bound.
> (i propose unbound, whereas original proposal was opposite)
>
> the error reporting becomes more meaningful by
> separating a massive subclass of "bad-matches"
> as its own class: "already bound"
> (in this regard the original proposal is
> slightly more complex than my counter-proposal)
> _______________________________________________
> eeps mailing list
> eeps@REDACTED
> http://erlang.org/mailman/listinfo/eeps
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20210115/746442b6/attachment-0001.htm>