Describe the bug
The Abstract Format documentation on the maint-29 branch does not describe the abstract forms introduced for native records by EEP-79.
The document still describes only traditional tuple-based record declarations and operations. It does not document native-record declarations,
imports and exports, module-qualified native-record names, or anonymous native-record operations.
This is a documentation issue. The parser and compiler already implement these forms.
Expected behavior
The Abstract Format documentation should describe the native-record attributes introduced in OTP 29:
%% -record #Name{...}.
{attribute,ANNO,native_record,{Name,Fields}}
%% -export_record([Name1, ..., NameN]).
{attribute,ANNO,export_record,[Name1, ..., NameN]}
%% -import_record(Module,[Name1, ..., NameN]).
{attribute,ANNO,import_record,
{Module,[Name1, ..., NameN]}}
It should also describe module-qualified native-record operations:
%% #Module:Name{...}
%% or a corresponding qualified pattern
{record,ANNO,{Module,Name},Fields}
%% Expression#Module:Name{...}
{record,ANNO,Expression,{Module,Name},Fields}
%% Expression#Module:Name.Field
{record_field,ANNO,Expression,{Module,Name},Field}
And anonymous native-record operations using #_:
%% #_{...} in a pattern
{record,ANNO,[],Fields}
%% Expression#_{...}
{record,ANNO,Expression,[],Fields}
%% Expression#_.Field
{record_field,ANNO,Expression,[],Field}
The documentation should explain that:
- {Module,Name} represents a module-qualified native-record name.
- [] in the record-name position represents an anonymous native-record operation.
- These forms were introduced for native records and are distinct from traditional tuple-based record forms.
Affected versions
Erlang/OTP 29 documentation, including the current maint-29 branch.
Native records were introduced in OTP 29, so earlier releases are not affected.
Additional context
The current maint-29 source document does not mention native_record or the qualified and anonymous native-record representations:
EEP-79 explicitly notes that parse transforms and other tools consuming abstract forms must be updated for native records. Documenting the exact
representations is therefore necessary for third-party tooling.
Describe the bug
The Abstract Format documentation on the maint-29 branch does not describe the abstract forms introduced for native records by EEP-79.
The document still describes only traditional tuple-based record declarations and operations. It does not document native-record declarations,
imports and exports, module-qualified native-record names, or anonymous native-record operations.
This is a documentation issue. The parser and compiler already implement these forms.
Expected behavior
The Abstract Format documentation should describe the native-record attributes introduced in OTP 29:
%% -record #Name{...}.
{attribute,ANNO,native_record,{Name,Fields}}
%% -export_record([Name1, ..., NameN]).
{attribute,ANNO,export_record,[Name1, ..., NameN]}
%% -import_record(Module,[Name1, ..., NameN]).
{attribute,ANNO,import_record,
{Module,[Name1, ..., NameN]}}
It should also describe module-qualified native-record operations:
%% #Module:Name{...}
%% or a corresponding qualified pattern
{record,ANNO,{Module,Name},Fields}
%% Expression#Module:Name{...}
{record,ANNO,Expression,{Module,Name},Fields}
%% Expression#Module:Name.Field
{record_field,ANNO,Expression,{Module,Name},Field}
And anonymous native-record operations using #_:
%% #_{...} in a pattern
{record,ANNO,[],Fields}
%% Expression#_{...}
{record,ANNO,Expression,[],Fields}
%% Expression#_.Field
{record_field,ANNO,Expression,[],Field}
The documentation should explain that:
Affected versions
Erlang/OTP 29 documentation, including the current maint-29 branch.
Native records were introduced in OTP 29, so earlier releases are not affected.
Additional context
The current maint-29 source document does not mention native_record or the qualified and anonymous native-record representations:
EEP-79 explicitly notes that parse transforms and other tools consuming abstract forms must be updated for native records. Documenting the exact
representations is therefore necessary for third-party tooling.