Skip to content

Allow func type param names in the field name subsection #7

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
bvisness wants to merge 1 commit into from
Closed

Allow func type param names in the field name subsection #7

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion document/core/appendix/custom.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -281,14 +281,17 @@ Field Names
...........

The *field name subsection* has the id 10.
It consists of an :ref:`indirect name map <binary-indirectnamemap>` assigning field names to :ref:`field indices <syntax-fieldidx>` grouped by the :ref:`type indices <syntax-typeidx>` of their respective :ref:`structure types <syntax-structtype>`.
It consists of an :ref:`indirect name map <binary-indirectnamemap>` assigning parameter and field names to :ref:`field indices <syntax-fieldidx>` grouped by the :ref:`type indices <syntax-typeidx>` of their respective :ref:`composite types <syntax-comptype>`.

.. math::
\begin{array}{llclll}
\production{field name subsection} & \Bfieldnamesubsec &::=&
\Bnamesubsection_{10}(\Bindirectnamemap) \\
\end{array}

.. note::
All :ref:`composite types <syntax-comptype>` can be described by the field name subsection, not just :ref:`aggregate types <syntax-aggrtype>`.

@rossberg rossberg Nov 13, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I would make such a general statement, since e.g. it doesn't make much sense for array types and none for continuation types. Perhaps better enumerate the types it can apply to?

@bvisness bvisness Nov 13, 2025

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the time of writing, it's just structs, arrays, and functions, and the existing terminology talks about "aggregate types" instead of just struct types. So really I was just sticking with that. But I agree that it really only makes sense for structs and functions right now.

What I'm more curious about is whether it's ok for all of them to use fieldidx. To be honest, it just seems exhausting to create a different type of index for every single thing.

@rossberg rossberg Nov 14, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be generic, you could just use plain idx (whose definition I just noticed was missing from the spec, but I just fixed that).



.. index:: tag, tag index
.. _binary-tagnamesec:
Expand Down
2 changes: 1 addition & 1 deletion document/core/syntax/modules.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -84,7 +84,7 @@ The index space for :ref:`locals <syntax-local>` is only accessible inside a :re

Label indices reference :ref:`structured control instructions <syntax-instr-control>` inside an instruction sequence. There are two index spaces for labels: one tracks the stack of active labels during validation, while the other tracks all labels defined in a specific function.

Each :ref:`aggregate type <syntax-aggrtype>` provides an index space for its :ref:`fields <syntax-fieldtype>`.
Each :ref:`composite type <syntax-comptype>` provides an index space for its :ref:`parameters <syntax-resulttype>` (for :ref:`function type <syntax-functype>`) or :ref:`fields <syntax-fieldtype>` (for :ref:`aggregate types <syntax-aggrtype>`). All such address spaces use :ref:`field indices <syntax-fieldidx>`.

@rossberg rossberg Nov 13, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason not to extend this to result types? There are languages that allow naming results symmetric to parameters.

@bvisness bvisness Nov 13, 2025

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the moment, simply because the text format doesn't allow names for results. That said, I did think about that, and it might not be that hard to add.

The one wacky bit is that it still wouldn't make sense to give names to results in actual function declarations. WASM isn't like Go where you can name a return value and then assign to it like a variable. So what would it mean to do (func $myFunc (result $foo i32) ...instrs)? What index would the name map to?

@rossberg rossberg Nov 14, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I guess the name section isn't really for the benefit of annotating source language names.



Conventions
Expand Down