Add EEP for native records #81

bjorng · 2025-11-06T05:36:34Z

No description provided.

josevalim

Thank you @bjorng and @garazdawi! The proposal is well written and building on top of records does a beautiful job of keeping the language changes minimal. Removing the undefined as default for fields is another great change, as well as having the optional of having "required fields" (which must be given on creation).

My only criticism to the proposal is that it doesn't discuss maps at all. For the last ~10 years, we have been using maps as replacements for records, and while native records aim to ease the migration between "records -> native records", there are no paths between "maps -> native records". Perhaps this is intentional, you are not expecting anyone to migrate between maps and native records, but then we have to deal with the side-effect that, as native records improve, a lot of code (specially in Elixir) will be forever suboptimal.

If I am allowed to spitball a bit, I'd love if "native records" were implemented as "named maps" or "record maps" behind the scenes. The proposal would stay roughly the same, the only differences are that:

Accessing a field in any record could use the existing map syntax and just work:
```
Expr#Field
```
Updating any record could use the existing map syntax and just work:
```
Expr#{Field1=Expr1, ..., FieldN=ExprN}
```

You could also support the proposed #_{...} syntax and it would additionally check it is a record and not a "plain map". is_map/1 would obviously return true for records but you could do a more precise check with is_record.

Regarding the key-destructive map operations, such as maps:put/3 or maps:remove/2, I'd make them fail unless you "untag" the map (or you could allow them to succeed but the tag would be removed at the end, which I find too subtle).

Overall, the goal would be to effectively unify records and maps, removing the decade-old question "records or maps". This would also provide a path for Erlang and Elixir to unify behind the same constructs, so I'd love to hear your opinions.

josevalim · 2025-11-06T06:52:04Z

eeps/eep-0079.md

+If no value is provided for a field, and there is a default field
+value in the native record definition, the default value is used. If
+no value is provided for a field and there is no default field value
+then a native record creation fails with a `badrecord` error.


Perhaps worth adding more context to the errors, such as {badrecord, {default_missing, key}}. I know format_error can be used (and have additional side-band information attached), but there may be a benefits in being upfront about it too?

This would also allow distinguishing from other errors below, such as {badrecord, not_found}, etc.

More context definitely better, even if it gives only one missing key out of several.

Yes please! I think more fine-grained errors would would be greatly beneficial for newcomers especially.

I've changed the error reason to {novalue,Field} (where novalue is a new error reason).

Accessing a field in any record could use the existing map syntax and just work:
Expr#Field

In erlang there is no existing map syntax for accessing a single field today,
that is still missing, was never implemented I guess because maps can have arbitrary terms as keys.

I guess it could be added for "literal" fields?
And it is really annoying to have to use the add record_name when accessing fields in records today, e.g. Rec#record_name.field

@dgud yes! I keep forgetting that it was part of EEP but not implemented.

And it is really annoying to have to use the add record_name when accessing fields in records today, e.g. Rec#record_name.field

I am assuming that, as long as you pattern match on the named record when the variable is defined, the compiler would be able to optimize "unamed" field access and updates?

I am assuming that, as long as you pattern match on the named record when the variable is defined, the compiler would be able to optimize "unamed" field access and updates?

Yes, that should be possible.

See the discussion in erlang/otp#9174 on a possible x[y] notation - @michalmuskala suggested M#[Field].

eeps/eep-0079.md

essen

Great work!

Would it make sense to have finer grained control on who can do what? For example restrict creation to the defining module while still providing access to fields; or read-only fields outside the defining module. Probably doesn't matter for 95% of use cases I reckon.

eeps/eep-0079.md

essen · 2025-11-06T10:32:59Z

eeps/eep-0079.md

+If no value is provided for a field, and there is a default field
+value in the native record definition, the default value is used. If
+no value is provided for a field and there is no default field value
+then a native record creation fails with a `badrecord` error.


More context definitely better, even if it gives only one missing key out of several.

essen · 2025-11-06T10:42:04Z

eeps/eep-0079.md

+The following syntax allows accessing field `Field` in any record:
+
+```erlang
+Expr#_.Field


This creates a new use case because we could have two records v1 and v2 that share some fields, and use this syntax to access the common fields. It probably needs to be highlighted.

bjorng · 2025-11-06T11:54:48Z

there are no paths between "maps -> native records". Perhaps this is intentional

We didn't really think about migrations from maps. Your suggestion seems reasonable. We will discuss this in the OTP team.

eeps/eep-0079.md

lpil

What a cool EEP! Thank you! I've a handful of questions

Language interop

One aspect of this which the document does not touch on that I think could be highly impactful for the BEAM ecosystem is language interop. Today each major language has a different preference for fixed key-value data structures:

Erlang: maps and records
Elixir: maps with a special field containing a module atom
Gleam: records

This creates some degree of friction when calling code from other BEAM languages. If they all were to largely use native records then this friction go away, making interop between languages would be a much better experience.

I'm not immediately seeing any problems for Gleam as we use records there, but it seems like it would be more challenging for Elixir there we use maps.

Adoption within existing OTP modules

It seems that in an ideal world that native records would be the ubiquitous data structure, once they are available. Would existing Erlang/OTP modules be updated to work with them?

Functions that expect classic records, tagged tuples, and maps could have new function clauses added to handle native records in a backwards compatible way, unless I am mistaken. It seems that due to not being compatible with maps or tuples there would be very little ability to update existing functions to return native records.

Is there something we could do here? Or is the expectation that Erlang/OTP code will use different data structures depending on how old it is?

Construction syntax

Is the only difference between the native and classic record syntaxes the # character in the name of the definition? This seems like it will be very error prone, and also hard for less familiar people to debug as the definition will be accepted by the Erlang compiler, but their attempts to construct the record will fail.

Thank you all!

lpil · 2025-11-06T16:16:10Z

eeps/eep-0079.md

+If no value is provided for a field, and there is a default field
+value in the native record definition, the default value is used. If
+no value is provided for a field and there is no default field value
+then a native record creation fails with a `badrecord` error.


Yes please! I think more fine-grained errors would would be greatly beneficial for newcomers especially.

eeps/eep-0079.md

lpil · 2025-11-06T20:47:01Z

eeps/eep-0079.md

+
+### Anonymous access of native records
+
+The following syntax allows accessing field `Field` in any record:


Is there a performance difference when using this syntax compared to using the non-anonymous syntax?

Are there situations in which one cannot use the anonymous syntax?

Is there a performance difference when using this syntax compared to using the non-anonymous syntax?

Yes, certain optimizations we are thinking about implementing will not be applied when using anonymous syntax.

Are there situations in which one cannot use the anonymous syntax?

No.

lpil · 2025-11-06T20:50:48Z

eeps/eep-0079.md

+
+1. Creation of native records cannot be done in guards
+
+2. `element/2` will not accept native records.


Tuple records can be constructed with field names (using the #blah{a=1,b=2} syntax) or without field names (using the {blah, 1, 2}) syntax. Do native records have a field-nameless #blah{1, 2} construction syntax?

No.

The nameless syntax for tuple records only works because traditional records are implemented using tuples.

lpil · 2025-11-06T20:51:49Z

eeps/eep-0079.md

+(tuples). So, their performance characteristics should align with maps
+(with insignificant overhead for runtime validation). Additionally,
+given that native-records are more specialized versions of maps (with
+all keys being atoms), there is potential for optimizations.


Is the expectation that native records will have inferior performance to tuple records?

We don't know yet, and it also depends on exactly which operations we are talking about. For example, updating multiple elements in a small map (no more than 32 elements) is quite efficient because it can be done in one pass, and similarly matching out multiple elements is also efficient because it can be done in one pass. Accessing one element at the time is more expensive for a map than for a tuple record.

In the first implementation to be released, native records will be implemented similar to how small maps are implemented, with similar performance. We have an idea for an optimization that would make it faster than maps.

bjorng · 2025-11-07T05:40:29Z

Functions that expect classic records, tagged tuples, and maps could have new function clauses added to handle native records in a backwards compatible way, unless I am mistaken. It seems that due to not being compatible with maps or tuples there would be very little ability to update existing functions to return native records.

Yes. If a function returns a tuple record, all we can do is to create a new function that returns a native record.

Or is the expectation that Erlang/OTP code will use different data structures depending on how old it is?

To some extent, yes. I think that is already the case.

If they all were to largely use native records then this friction go away, making interop between languages would be a much better experience.

Agreed.

lpil · 2025-11-07T07:46:25Z

Thank you @bjorng.

To confirm: all fields must have names? There are no positional fields?

Can one define a record which does not have any fields?

-record #none{}.
-record #some{value = term()}.
-type option() :: #none{} | #some{}

bjorng · 2025-11-07T07:59:23Z

To confirm: all fields must have names?

Yes.

Can one define a record which does not have any fields?

Yes.

dgud · 2025-11-07T08:43:35Z

Great work!

Would it make sense to have finer grained control on who can do what? For example restrict creation to the defining module while still providing access to fields; or read-only fields outside the defining module. Probably doesn't matter for 95% of use cases I reckon.

We are trying to limit the scope here to try to get it in to 29.

Hmm, this would require some additional syntax, 'private' | 'protected' | 'public' (borrowing from ets access types), personally
I don't think this is necessary nor wanted, Opaqueness on fields have been up for discussion but dropped for now at, implementation and reflection reasons.

RaimoNiskanen · 2025-11-07T08:45:25Z

@lpil wrote:

Is the only difference between the native and classic record syntaxes the # character in the name of the definition? This seems like it will be very error prone, ...

It is a different format, not only the # character, it is like record creation:

-record(foo, {a, b, c}).
%% vs.
-record #foo{a, b, c}.

So there is also a comma and parentheses that are different.

tsloughter · 2025-11-07T09:40:49Z

I don't see the concern raised that we'll now have record, native records and maps. I know they all serve different purposes, but the differences are slight and new users definitely get confused about which to use. I don't think it should be a blocker to adding a new data structure that can help improve devex or performance when choosing the right one but it does worry me that this can't replace records.

Related to not replacing records, I think -record being overloaded is confusing. To be clear, I don't like the idea of -native_record either.

essen · 2025-11-07T11:11:44Z

Hmm, this would require some additional syntax, 'private' | 'protected' | 'public' (borrowing from ets access types), personally I don't think this is necessary nor wanted, Opaqueness on fields have been up for discussion but dropped for now at, implementation and reflection reasons.

Right it's something that likely doesn't have to be done at runtime, but it is important to consider at least in the documentation part, as internal fields definitely shouldn't be documented. Read-only fields can be marked as such easily in the text. But this depends on what the documentation will look like I suppose.

bjorng · 2025-11-07T13:52:55Z

Update: there can now be two distinct errors when Rec#rec.field fails: {badrecord,Term} or {badfield,field}.

RaimoNiskanen · 2025-11-07T15:42:01Z

@tsloughter wrote:

Related to not replacing records, I think -record being overloaded is confusing. ...

"Not replacing records" is really phrased: not "Replacing all tuple record usage scenarios.", and "Replace most tuple-record usages without having to update anything but the declaration.".

With that in mind I think overloading -record may be more good than bad.

tsloughter · 2025-11-07T16:17:06Z

@RaimoNiskanen unless it outright replaces, 100%, named tuple records I think using -record will cause additional confusion to the confusion that will already exist from there being 2 types of records and maps.

I take it there are a million reasons -type shouldn't and can't also define a record:

-type #pair(A, B) :: #pair{
                           first :: A,
                           second :: B
                          }.

At first I wanted #{} but that is already used by maps!

I can concede there is no good alternative to -record... except maybe -frame (I kid, I kid). But making the times that tuple records are needed be as small as possible may be important though, to not have Erlang grow its reputation of confusing. Probably ets usage is the biggest one there.

lpil · 2025-11-07T16:33:36Z

I do share the concern that the similar syntax is confusing, and the difference being 2 characters of punctuation makes it challenging to differentiate between the two when reviewing code.

I can concede there is no good alternative to -record... except maybe -frame

struct was the one option that came to mind.

-struct #state{
  values = [] :: list(number()),
  avg = 0.0 :: float()
}.

Elixir does already have "defstruct", though that construct does seem very similar to this proposal in design and purpose.

potatosalad · 2025-11-10T08:59:04Z

Question: Behavior when adding a field across distributed nodes

Consider this scenario:

Node A (old code):

-record #state{count = 0, name = "default"}.
State = #state{count = 5, name = "server1"}

Node B (new code):

-record #state{count = 0, name = "default", version = 1}.

When Node A sends a State record to Node B:

Reading works fine: Node B can read State#state.count and State#state.name since those fields exist in the record value.
Reading the new field fails: State#state.version will raise {badfield, version} because the field doesn't exist in the record value (it was created with the old definition).
Pattern matching is unclear: Can Node B do #state{version = V} = State? Based on the spec: "Pattern matching fails if the pattern references a FieldK and the native-record value does not contain this field." This would fail.
Updating appears problematic: Can Node B do State#state{version = 1} to add the missing field? The EEP states: "A native-record value is updated according to its native-record definition" and "An update operation fails with a {badfield,FN} error if the native-record update expression references the field FN which is not
defined (in the structure definition)."

Issue: This seems to check against the definition on Node B, not the fields in the value from Node A. It's unclear whether the update would:

Succeed and add the version field to the record value
Fail because version doesn't exist in the value
Create a new record with all three fields (losing the old value's identity)

potatosalad · 2025-11-10T09:02:48Z

Question: Field renaming across nodes

Consider this scenario where a field is renamed:

Node A (old code):

-record #user{id, username, city}.
User = #user{id = 1, username = "alice", city = "Stockholm"}

Node B (new code - username renamed to name):

-record #user{id, name, city}.

When Node A sends User to Node B:

The record value still contains username: The field names are captured when the record is created, so the value has fields [id, username, city].
Node B cannot read the new field: User#user.name raises {badfield, name} because the value doesn't have a name field.
Node B CAN still read the old field: User#user.username should work because field access doesn't consult the definition—only the value. But is this problematic
because username isn't in Node B's definition?
Pattern matching breaks: case User of #user{name = N} -> N end fails because name doesn't exist in the value.

Issue: Field renames appear to be breaking changes in distributed systems.

The EEP states:

to perform read operations on native-record values — accessing native-record fields and pattern matching over native-record values — the runtime does not consult the current native-record definition.

This means reading works purely based on the value's fields, not the definition. So:

Old nodes can't read renamed fields (they use the old name)
New nodes can't read renamed fields (the value has the old name, pattern matching fails)
Updating is impossible (the definition has the new name, the value has the old name)

potatosalad · 2025-11-10T09:07:11Z

Question: Removing a field

Consider this scenario:

Node A (old code):

-record #config{host, port, legacy_timeout}.
Config = #config{host = "localhost", port = 8080, legacy_timeout = 5000}

Node B (new code - legacy_timeout removed):

-record #config{host, port}.

When Node A sends Config to Node B:

The removed field still exists in the value: The record value contains [host, port, legacy_timeout] because that's what Node A created.
Reading removed fields: Based on the spec, Config#config.legacy_timeout should still work on Node B because field access doesn't consult the definition—it only checks if the field exists in the value. This means:

Code on Node B can accidentally read fields that "don't exist" in its definition
Linters/dialyzer on Node B would flag legacy_timeout as an error, but it works at runtime
Might this create a confusing situation for developers?

Pattern matching works: case Config of #config{host = H, port = P} -> ... end works fine (only matching fields that exist in both value and definition).

Issue: The interaction between field access (which ignores definition) and pattern matching (which may or may not check definition) is unclear.

bjorng · 2025-11-17T08:59:24Z

It turns out that I had failed to fully update the EEP regarding when a record definition is consulted (or not). In our internal meetings we had decided that the definition for a native record is only used when creating a record. All update and read operations will only refer to the value of record (which includes the names, whether it was exported at value-creation time, the name of the record, and of course all values).

I've now pushed another commit to hopefully make that clearer.

michalmuskala · 2025-11-17T12:44:55Z

If the definition is never consulted on update, how do you upgrade values to the new definition? Do you have to explicitly deconstruct & reconstruct and keep version of the code doing that for all possible values that are live in the system?
With the previous design, upgrading a value (given all new fields have a default) was potentially as simple as OldValue#record{}, and could handle all sorts of versions.
AFAIK the intention of the previous design was to define update in terms of creation + read from the existing value for fields that weren't explicitly provided

bjorng · 2025-11-18T04:56:24Z

If the definition is never consulted on update, how do you upgrade values to the new definition? Do you have to explicitly deconstruct & reconstruct and keep version of the code doing that for all possible values that are live in the system?

Yes. Upgrades must be done explicitly.

With the previous design, upgrading a value (given all new fields have a default) was potentially as simple as OldValue#record{}, and could handle all sorts of versions.

While the design was simple, we discovered that the actual implementation was far from simple, especially when more than one node is involved (or even when loading from the disk native records written by a previous instance of the runtime system). Also, we are not sure that is easy for the user to understand and handle all the implications of automatic upgrades of native records.

eeps/eep-0079.md

Apply Rickard's suggestions.

This is an implementation of native records as desribed in EEP-79 (erlang/eep#81). Co-authored-by: John Högberg <john@erlang.org> Co-authored-by: Isabell Huang <isabell@erlang.org> Co-authored-by: Ilya Klyuchnikov <ilya.klyuchnikov@gmail.com>

Maria-12648430 · 2026-01-05T12:51:04Z

tl;dr: ❤️❤️❤️

Disclaimer: I haven't read all comments here in tiniest detail, so sorry if I repeat a question that has already been answered 😜

As I understand it, native records, exported or not, can be sent to any other process (!) just like anything else. If the target process is running a different module, how would you receive-match on a native record that is not exported by the defining module? Would that even be possible? And if not, how should something like this be handled by the receiving process?

Another thing that AFAICS is missing from the doc is (non-)extensibility of native records. (Note that I'm not saying that we should have that. But IMO it should at least be discussed and forthwith mentioned, Goals, Hard/Soft Not-Goals, whatever). That is to say, should or should we not have a way to define "general" native records which other native records can extend like "record y is record x with this and that additional field"? And in that line, how would matching on something like this work?

tazjin · 2026-01-06T23:33:11Z

eeps/eep-0079.md

+As it can be seen from the next sections, working with native records outside of
+the defining module needs using fully qualified names of the native records:
+`#misc:user{}`, ... This quickly may become too cumbersome and verbose. The
+`-import_record` directive works similar to the `-import` and `-import_type` directives.


Why do we need explicit directives for each case, instead of folding e.g. import_record into one of the existing ones? Is this an explicit design choice, or a technical restriction?

tazjin · 2026-01-06T23:40:44Z

eeps/eep-0079.md

+  not defined (in the structure definition).
+
+* No value is provided for a field FN and the native-record definition
+  has no default value for FN.


Above it's said that this fails with {novalue,FieldName}. Which is true? Or is this something like a {badrecord, {novalue, FieldName}}?

tazjin · 2026-01-06T23:41:57Z

eeps/eep-0079.md

+* The field `Field` is not defined in the native-record value.
+
+* The definition of the record was not exported when the native-record
+  value was created, and it is now used outside its defining module.


Shouldn't the non-exported case also be a badrecord error in the anonymous case? Otherwise that seems oddly inconsistent.

tazjin · 2026-01-06T23:43:07Z

eeps/eep-0079.md

+native-record value.
+
+When a field from a native-record value is accessed, the current
+native-record definition is **not** consulted.


But is it consulted at compile-time, or can I write an expression that accesses a field that doesn't exist in my record as per the current code?

tazjin · 2026-01-06T23:47:03Z

eeps/eep-0079.md

+An update operation fails with a `{badfield,FN}` error if:
+
+* The native-record update expression references the field FN which is
+  not defined native-record value.


What if older code on another node sends me a record, and I want to (blindly) update a field in it that my code knows about but the other node doesn't (yet)?

I'm likening this to Protocol Buffers, which let you always do whatever you want with known (to you) fields, while otherwise preserving the message structure.

Aha, I saw the comment saying upgrades are explicit only. Hm. Protobufs have this nice property of being able to deal with values based on your current knowledge of the structure, but they make the cost of this explicit to the user (fields use numeric IDs, and you are responsible for managing them). I wonder if there's a middle ground, though.

tazjin · 2026-01-07T00:16:48Z

Good proposal! My overall thought is that I see this as a step towards "cleaning up" struct-like types, i.e. types with known fields. Strongly agree with @josevalim on the unification of maps and records due to this.

In fact, this non-goal from the proposal irks me a bit:

Replacing all tuple record usage scenarios.

This can be read in two ways:

Native records shouldn't support all concrete uses in code that tuple records have (which makes sense, e.g. for plain pattern matching on the underlying tuples, which would obviously be unsupported).
Native records do not aim to be "better" at all use-cases that tuple records are good at.

I think that being better should be a design goal: Native records look, in many ways, like "Records V2" - which sets an expectation (and, imho, a reasonable one) that they should be strictly better than "Records V1".

I also think introducing as little new syntax and definitions as possible for this would also be great. If there was a way to just declare a record in essentially "the map type language", maybe literally through the -type keyword as somebody suggested above, and get additional compiler optimisations from that - it would be amazing.

This is an implementation of native records as desribed in EEP-79 (erlang/eep#81). Co-authored-by: John Högberg <john@erlang.org> Co-authored-by: Isabell Huang <isabell@erlang.org> Co-authored-by: Ilya Klyuchnikov <ilya.klyuchnikov@gmail.com>

yarisx · 2026-01-15T08:11:29Z

When reading about public | private access of fields in another comment I've got a question regarding native records hierarchy:

as I understand it is possible to define a native record that has a field which itself is a native record (although there should be some work when creating values of such type)
if so, it is possible (intentionally or accidentally) to export the "outer" record definition without exporting the "inner" record definition
What will be the behaviour of code manipulating instances of the "outer" record type? As I can understand, as long as the code does not try to manipulate the field(s) of the "inner" record everything should be fine, including pattern-matching on the name of the "inner" record (but not its fields).

UlfNorell · 2026-01-15T08:58:52Z

This looks very nice! I would like to suggest a

-spec to_map(record()) -> #{atom() => term()}.

in the reflection API to make it easy to write generic traversals supporting native records:

foo(BaseCase) -> ...;
foo([H|T]) ->
    [foo(H)|foo(T)];
foo(M) when is_map(M) ->
    maps:from_list(foo(maps:to_list(M));
foo(R) when is_record(R) ->
    records:create(records:get_module(R), records:get_name(R), foo(records:to_map(R));
foo(X) -> X.

This is an implementation of native records as desribed in EEP-79 (erlang/eep#81). Co-authored-by: John Högberg <john@erlang.org> Co-authored-by: Isabell Huang <isabell@erlang.org> Co-authored-by: Ilya Klyuchnikov <ilya.klyuchnikov@gmail.com>

zachallaun

Excited to see this! Comments are only related to minor typos found during my read-through.

zachallaun · 2026-01-17T14:09:56Z

eeps/eep-0079.md

+Soft Non-Goals
+--------------
+
+Here are some features we might consider implementin in a future release.


Suggested change

Here are some features we might consider implementin in a future release.

Here are some features we might consider implementing in a future release.

zachallaun · 2026-01-17T14:17:08Z

eeps/eep-0079.md

+
+* a tuple record
+* a local native record
+* a native record imported using `-import_record()'


Suggested change

* a native record imported using `-import_record()'

* a native record imported using `-import_record()`

zachallaun · 2026-01-17T14:19:28Z

eeps/eep-0079.md

+
+In OTP 29, the default value can only be an expression that can be
+evaluated to a constant at compile-time. Essentially, the allowed
+expressions are guard expression, with the following additional


Suggested change

expressions are guard expression, with the following additional

expressions are guard expressions, with the following additional

zachallaun · 2026-01-17T14:23:19Z

eeps/eep-0079.md

+When a native-record value is created, it “captures” key information
+from the current native-record definition, namely:
+
+* They fully qualified name of the native-record (module name and


Suggested change

* They fully qualified name of the native-record (module name and

* The fully qualified name of the native-record (module name and

mikpe · 2026-01-17T16:32:44Z

eeps/eep-0079.md

+native-record value.
+
+When a field from a native-record value is accessed, the current
+native-record definition is **not** consulted.


Can I assume this means that accesses only use information contained in or referenced by the native record value itself, and there is no lookup to the current version of the native record's creating module?

I understand that implementation details are outside the scope of a language proposal, but it would be useful to have (or link to) a discussion about possible implementations. Understanding the performance implications of native records compared to maps and tuple records would be essential before changing code to use them.

mikpe · 2026-01-17T16:39:51Z

eeps/eep-0079.md

+
+The main advantage of the native records is that more fields can
+be added to the definition without having to recompile all code
+that uses the record.


If that's true then it seems like a fairly weak motivation to me.
Below you briefly write that they could be faster than maps, and that seems a more reasonable motivation.

The rest of the EEP has a lot of stuff about syntax, restrictions, and how-to-do-X, but very little in terms of why I, the user, would want to use these things.

bjorng self-assigned this Nov 6, 2025

bjorng closed this Nov 6, 2025

bjorng reopened this Nov 6, 2025

josevalim reviewed Nov 6, 2025

View reviewed changes

essen reviewed Nov 6, 2025

View reviewed changes

Add EEP for native records

f5b4834

bjorng force-pushed the bjorn/native-records branch from a4bdeec to f5b4834 Compare November 6, 2025 11:44

fixup! Add EEP for native records

3e899bf

eproxus reviewed Nov 6, 2025

View reviewed changes

eeps/eep-0079.md Outdated Show resolved Hide resolved

eeps/eep-0079.md Outdated Show resolved Hide resolved

bjorng added 2 commits November 6, 2025 13:50

fixup! Add EEP for native records

06bad8e

fixup! Add EEP for native records

9ed9988

lpil reviewed Nov 6, 2025

View reviewed changes

fixup! Add EEP for native records

eef8179

fixup! Add EEP for native records

d2ab33d

bjorng force-pushed the bjorn/native-records branch from 997a60f to d2ab33d Compare November 7, 2025 13:43

bjorng force-pushed the bjorn/native-records branch from 4024026 to dc31588 Compare November 17, 2025 08:05

fixup! Add EEP for native records

d047aa4

bjorng added 2 commits November 17, 2025 13:58

fixup! Add EEP for native records

67e7525

fixup! Add EEP for native records

2d08ed5

rickard-green reviewed Nov 19, 2025

View reviewed changes

fixup! Add EEP for native records

376a2d0

Apply Rickard's suggestions.

bjorng force-pushed the bjorn/native-records branch from 601ecf5 to 376a2d0 Compare November 19, 2025 05:44

michalmuskala mentioned this pull request Dec 22, 2025

docs: options representation in new APIs erlang/otp#10502

Open

tazjin reviewed Jan 6, 2026

View reviewed changes

zachallaun reviewed Jan 17, 2026

View reviewed changes

mikpe reviewed Jan 17, 2026

View reviewed changes


		### Anonymous access of native records

		The following syntax allows accessing field `Field` in any record:


		1. Creation of native records cannot be done in guards

		2. `element/2` will not accept native records.

	Here are some features we might consider implementin in a future release.
	Here are some features we might consider implementing in a future release.

	* a native record imported using `-import_record()'
	* a native record imported using `-import_record()`

	expressions are guard expression, with the following additional
	expressions are guard expressions, with the following additional

	* They fully qualified name of the native-record (module name and
	* The fully qualified name of the native-record (module name and

Add EEP for native records #81

Are you sure you want to change the base?

Add EEP for native records #81

Conversation

bjorng commented Nov 6, 2025

Uh oh!

josevalim left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

essen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bjorng commented Nov 6, 2025

Uh oh!

Uh oh!

Uh oh!

lpil left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Language interop

Adoption within existing OTP modules

Construction syntax

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bjorng Nov 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bjorng commented Nov 7, 2025

Uh oh!

lpil commented Nov 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bjorng commented Nov 7, 2025

Uh oh!

dgud commented Nov 7, 2025

Uh oh!

RaimoNiskanen commented Nov 7, 2025

Uh oh!

tsloughter commented Nov 7, 2025

Uh oh!

essen commented Nov 7, 2025

Uh oh!

bjorng commented Nov 7, 2025

Uh oh!

josevalim left a comment •

edited

Loading

lpil left a comment •

edited

Loading

bjorng Nov 7, 2025 •

edited

Loading

lpil commented Nov 7, 2025 •

edited

Loading

bjorng commented Nov 17, 2025 •

edited

Loading

michalmuskala commented Nov 17, 2025 •

edited

Loading

Maria-12648430 commented Jan 5, 2026 •

edited

Loading