EEP 79: Native Records

Erlang News & Announcements Official Proposals
1

We want to introduce a new native datatype to Erlang: native records. Although replacing all tuple records with native records is not our design goal, we hope to make it simple to upgrade most tuple records to native records. That is why native records use the same syntax as the existing tuple records except in declaration.

Here is the pull request for the EEP.

Our plan is to include native records in RC1 of OTP 29. In the later RCs of OTP 29, we will add support for native records to more applications, like syntax tools and Dialyzer. By OTP 30, we will add performance improvements and broader support for tools, as described in the EEP.

17 Likes
Erlang Forums 2026 Update!
3

What does native mean in this context, are there some hardware instructions used for performance gains or something else?

1 Like
4

Native means that it is a real Erlang data type, not only syntactic sugar on top of tuples.

10 Likes
5

Overall, looks good and interesting. It looks to be useful for gen_* states. I find it slightly confusing that non-exported record types can be still used outside the module, but I guess this is unavoidable as data can leave the module in various ways.

I was wondering, do we really need the underscore for anonymous access and update? I mean in the

Expr#_.Field

expression the three consecutive punctuation mark characters are approaching “line noise territory”. Would using the same syntax as the tuple-records lead to slightly worse performance? I mean the runtime would know the type of Expr at this point and based on the type the runtime would know how to access Field.

6

I haven’t looked at the Erlang parser, but is it that difficult to extend the -import attribute to support these native records? Then we can have something like this?

-import(example1, [#user, #pair]).
-import(example1, [#user, #pair, fun1/0, fun2/1]).

Also, why can’t the -record(...) attribute be upgraded to allow the definition of native records?

% Old 
-record(person, {name, age}).

% New
-record(#person, {name, age})

There are so many new attributes and inconsistencies introduced or about to be introduced lately:

  • new -import_type attribute
  • new -import_record attribute
  • new attribute formats: -doc(“…”) OR -doc “…”, why not just -doc(“…”)?

I understanding introducing new functionality can’t always be accommodated by existing structures, but it would be nice if we could attempt. Consistency is beautiful!

1 Like
7

A long time ago, I wanted to implement an incremental marking feature for data type modifications in Erlang to facilitate the storage or broadcasting of incremental data. However, I was never successful because I didn’t have a thorough understanding of Erlang’s parse_transform. Recently, I saw this new Native Records data type, which reminded me of what I wanted to do before. With the help of AI programming, I implemented a feature that marks the updated fields after a record update. The relevant code is available at https://github.com/ErlGameWorld/ePtDirty . I think it would be great if Native Records natively supported this incremental modification marking feature.

8

This is not actuallly new. This module is 100% valid (and I like it much more than the version with parentheses :slight_smile: ):

-module my_module.

-export [my_fun/0].

my_fun() -> {look, ma, no, parentheses}.

The only “problem” is this one

1 Like
9

I’ve pushed some updates to the pull request for the EEP. There is now also a PR for the implementation:

Implement native records by bjorng · Pull Request #10617 · erlang/otp · GitHub