EEP-79 native records and structs

Native records does not check all fields, it only checks the fields you have listed + the module:record name.

From EEP-79:

When a native-record value is matched, its captured native-record definition is consulted.

So it behaves very similarly to how Structs except you cannot use the :maps API to manipulate it. This ties into how native records work with multiple versions, that is you can access old native records of the same module:record as long as you are only reading/changing fields that exist in it.

I don’t know which way that Elixir will take with native-records as Elixir has a similar problem as Erlang’s tuple records in this regard, that is the implementation of structs has leaked through into user code and thus it is hard/impossible to do a switch without the user deciding that it is safe to switch.

Slightly related, Structs allow to match on the module name, but it is not yet possible with native records - there is an issue already Allow pattern matching (or guards) on native records module/name · Issue #10861 · erlang/otp · GitHub

Given that native records will be experimental in Erlang/OTP 29 (and maybe also in Erlang/OTP 30), it seems like this is the time to provide feedback like this

the more reasonable/sane approach would seem to be 2 (new semantics for records/native-records meaning probably new syntax around it), maybe with converging both in a far future 2.0 elixir version.

I hope converging both, and maybe it’s a good reason for 2.0 to not be that far in the future but as soon as native records are stable, in one or two years? If structs could be implemented as native records, it would improve interoperability with Erlang libraries (and maybe Gleam could adopt them as well?).

Unless I understood the EEP wrongly I guess it’s very different from structs given this:

When a native-record value is created, it “captures” key information from the current native-record definition, namely:

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

• Field names

• Whether it is exported (through -export_record)

so the moment you modify it to have a different shape, you gonna need to create a new data structure(being converting the native-record to map/proplist, or moving to a different native-record). structs even if you modify them, they keep being the same data structure(maps) and pass guards validation even if malformed data is given. I understand that elixir syntax sugars around structs try to guardrail against those malformed data, but just by being a new data structure native records have more guardrails around it then structs.

I agree, that’s why I think it would be good to discuss having it supported now and maybe in a very far future of elixir 2.0 have it converge. That’s my point to start the discussion. first highlighting how different it is from structs and why it’s good to have a first class support to it in Elixir even if we have structs.

Yep. for now I’d like to know what are the thoughts of Elixir core team on adding support to it, maybe making anonymous dot notation to work on it. and possibly access behavior implementation for it. probably around erlang 31 when the thing gets more solid.

i wouldn’t rush it. initially i just want it to not being ignored

Citation needed for half-baked tuple record support. Record module exists for interoperability and I’m sure it could be improved. Have you tried submitting PRs for bugs or missing features?

2 years ago I asked in this forum if there was a reason for elixir records to not behave the same way they behave on erlang. i didn’t open a bug for this bc if the way it is right now is desired, there is no reason to fix it(and I assume is desired bc it’s a pretty obvious issue on implementation side).

I’m not saying it’s half-baked as an offense to maintainers, but as a description of a thing that works kinda the same but with it’s own oddities to be functionally usable but without being fully part of the language(and I understand that its a design choice to make stuff simpler, more syntax would be conflicting with struct and map dot notation for example).

If I need to define more than one struct in a module, I define them in bare modules that have nothing but defstruct and put all functions in the main module. The main module and the struct defining modules can still live in the same file, which is all that matters to me.
.

the problem is not creating files, and having a way to bypass creating a file doesn’t make it less of a problem.it reduces the friction, but doesn’t eliminate the problem that is: module name conflicting on being a function namespace or a data type identifier.

the two points I made was related to native records being a compelling feature that worth the effort of being fully brought to elixir(even if in a slow pace). i’m not trying to solve structs problems.

Doesn’t reducing the friction make it less of a problem? Unless your definition of “problem” is not what I have. Do you have an example to show why “module name conflicting on being a function namespace or a data type identifier” has made it hard to express what you want to express in Elixir?

module name is a an atom, and in elixir it’s atom prefixed by Elixir., atoms have a hard length limit on 255 characters. if you’re using module names not only as function namespace but also as a data type identifier, you have a tendency to add more stuff to that namespace, making it easier to offend the hard limit on 255 characters. and it can easily offended when people try to make structs describe deeply nested data.

keeping module name as just a namespace, and making the record have it’s own name inside that namespace, stops the tendency to deeply nest one namespace in the other. you can describe the nested data in the same module with each nested level being it’s own independent record and composing on them(as it already happens with xmerl for example).