Any reason for the different semantics with records in Elixir?

Questions / Help
1

So I was experimenting with records in elixir and I found it very odd the different behaviour between using records in erlang.

defmodule R do
  require Record
  Record.defrecord :some, [:a, :b, :c]
end

R.some({:some, 1}, :a)

This would return 1 instead of returning a error of bad record.
while in erlang:

1> rd(some, {a, b, c}).
some
2> B = {some, 1}.
{some,1}
3> B#some.a.
** exception error: {badrecord,{some,1}}
2

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}.

1 Like
3

both examples do the same. the <record_name>/2 macro doesn’t create a record, it fetches the field of a record. <record_name>/0 and <record_name>/1 macros are the ones that create records.

from elixir docs:

The following macros are generated:
name/0 to create a new record with default values for all fields
name/1 to create a new record with the given fields and values, to get the zero-based index of the given field in a record or to convert the given record to a keyword list
name/2 to update an existing record with the given fields and values or to access a given field in a given record

https://hexdocs.pm/elixir/Record.html#defrecord/3

4

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

5

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.

1 Like