I fully support what Loïc Hoguin wrote in mailing list:
If annotations are generalized we could instead have
f(X, Y) →
case X of
{a, ^match Y} → {ok, Y};
_ → error
end.and we could use them for other things such as
^remote Pid ! Msg
which can then be used by other tools to help better understand the
code. I don’t think we would end up with too many annotations ultimately
so using a single word for this is probably enough. No opinion on the ^
character.Since this is annotations, this ought to be optional, although of course
teams may decide to force the use of ^match in their own projects along
with the related compiler warnings.
but I would go even further to say that we don’t need any special notation for this
and annotations could be any erlang term. For example:
remote Pid ! msg
{remote, "some other useful information"} Pid ! Msg
{provider, <<"serialization">>}
f(X) -> ....
then these can be used by parse transformations (one way how to implement and enforce pinning)
or other tools that require more context form programmer. This of course leads to “meta” representations/programming which i know lot of people dislike.
To discourage blatantly annotating everything with nonsence and/or clutter code, compiler could make error for all “unconsumed” annotations.
I can see this kind of proposal to be met with a lot of push back from the community and some possible arguments could be:
- parse transformations or transformational tooling is not transparent
- adding annotations changes spirit of erlang
- it diminishes readability (do not clutter)
but when I see this kind of argument i remember quote from Bjarne Stroustrup:
“Every new powerful feature will be overused and misused”
moderation and care should eventually prevail and features like this could be very useful for library and frameworks authors.
IMO pinning operator is too narrow feature to be worth while, but it can be a good opportunity to start thinking about how to provide more information to tools that we already have.