New EEP draft: Pinning operator ^ in patterns

[Fred Hebert]

On 12/24, Richard Carlsson wrote:
>In this case, there is no new binding of `Y`, and the use of `Y` in
>the fun clause body refers to the function parameter.  But it is also
>possible to combine pinning and shadowing in the same pattern:
>
>    f(X, Y) ->
>        F = fun ({a, ^Y, Y})  -> {ok, Y};
>                (_) -> error
>            end,
>        F(X).
>
>In this case, the pinned field refers to the value of the function
>function parameter, but there is also a new shadowing binding of `Y`
>to the third field of the tuple.  The use in the fun clause body now
>refers to the shadowing instance.
>
>Generator patterns in list comprehensions or binary comprehensions
>follow the same rules as fun clause heads, so with pinning we can for
>example write the following code:
>
>    f(X, Y) ->
>        [{b, Y} || {a, ^Y, Y} <- X].
>
>where the `Y` in `{b, Y}` is the shadowing instance bound to the third
>element of the pattern tuple.
>

I don't understand the rationale here. If ^Y and Y are distinct in these 
patterns, they should be named differently. It sounds unsafe to let the 
values diverge.  The rationale in fact tries to expand on it there:

>Furthermore, in the odd case that the pattern would both need to
>access the surrounding definition of `Y` as well as introduce a new
>shadowing binding, this can be easily written using pinning:
>
>    f(X, Y) ->
>        F = fun ({a, ^Y, Y})  -> {ok, Y};
>                (_) -> error
>            end,
>        F(X).
>
>but in current Erlang, two separate temporary variables would be
>required:
>
>    f(X, Y) ->
>        OuterY = Y,
>        F = fun ({a, Temp, Y}) when Temp =:= OuterY -> {ok, Y};
>                (_) -> error
>            end,
>        F(X).
>

But it still makes no sense why you would require Temp to be equal to Y 
but only use the inner binding specifically. Semantically there is no 
benefit to be had there, and this introduces a rebinding that isn't 
required?

The one implementation detail that could have an impact there would be 
based on the values of binaries references where there is specifically a 
desire to use one more than the other.

I'm opposed only to this specific part of the RFC as not helping making 
things clearer. Just name the variables differently and keep the 
shadowing warning.