Unlike in your Elixir example, in your Erlang example, you aren’t actually creating a #some record.

This should work instead:

1> rd(some, {a, b, c}).
some
2> B = #some{a = 1}.
#some{a = 1,b = undefined,c = undefined}
3> B#some.a.
1

The reason the Elixir example works is definitely interesting. It winds up calling :erlang.element(2, {:some, 1}), which only works for the :a field. If you try to get :b or :c, it should raise an exception about the index being out of range.

I suspect the core misunderstanding might be that {:some, 1} is not a valid ‘some’ record. The tuple representation of #some{a=1} is {some, 1, undefined, undefined}.

both examples do the same.

The intent of the examples is the same, but <record_name>/2 uses :erlang.element/2 to fetch a field. The Elixir example works on the {:some, 1} input, while the Erlang one doesn’t, because it first checks that the input is a ‘tagged tuple’ with the appropriate arity (in this case; 4).

this is exactly what i’m reporting… the elixir version doesn’t identify it as a bad record at all.

Right!

I guess we could conclude that the reason why the semantics are different in Elixir is because the private function Record.get/4 uses the :erlang.element/2 BIF. This avoids checking that the input is a tuple of the correct arity, and that the ‘tag’ element of the tuple matches the record tag. The result of this is that <record_name>/2 will work for tuples that aren’t necessarily records.