> 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 <[email protected]> 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 > [email protected] > http://erlang.org/mailman/listinfo/eeps >
_______________________________________________ eeps mailing list [email protected] http://erlang.org/mailman/listinfo/eeps
