Record selectors (again)

[Bjorn Gustavsson]

Yes, I agree. We also want to change the behaviour to something
like

unsafely_access_a(R) ->
     case R of
        {rec,A,_} -> A;
        _ -> erlang:fault(badarg)
     end.

similar to how other record operations are handled.

Unfortunately, we will probably not have time to do the stricter
checking for R10. The reason is that the record access operation
could be nested inside an arbitrary expression, and that also need
to be handled properly in all cases (probably, the record access
needed be lifted out and done before the expression).

/Bjorn

Kostis Sagonas <kostis@REDACTED> writes:

> This is a plea for a small change to the compilation of the
> record selector operations in BEAM.  Apologies for opening
> up an old thread, but I cannot see any good excuses for
> maintaining the following behaviour...
> 
> The code:
> ==========================================================
> -module(rec).
> -export([unsafely_access_a/1]).
> -record(rec,{a,b}).
> 
> unsafely_access_a(R) ->
>     R#rec.a.
> ==========================================================
> 
> currently gets preprocessed to:
> ==========================================================
> unsafely_access_a(R) ->
>     erlang:element(2,R).
> ==========================================================
> 
> which loses all information that the `a' field of an `rec'
> record is requested. This is VERY user-unfriendly and REALLY
> error-prone.  For example, the following happily returns:
> 
> 1> rec:unsafely_access_a({gazonk,[total_crap],bar,42}).
> 
> 
> Modulo returning different exceptions and a slight performance
> hit (which should not be prohibitive or a reason for not doing
> this change in OTP), it seems to me that the following code
> follows the intention of the programmer much more closely:
> 
> ==========================================================
> unsafely_access_a(R) ->
>     {rec,A,_} = R,
>     A.
> ==========================================================
> 
> Perhaps a better translation than the one I suggest is possible,
> but clearly something needs to be done about this Erlang-ism...
> 
> Kostis.
> 

-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB