Allow func type param names in the field name subsection#7
Conversation
2be388b to
50f6907
Compare
It is very natural to extend the field name subsection to include parameters for function types. The binary encoding for function types would be identical, and func types are already included under "composite types" in the spec anyway. In this patch I have updated to keep the name "field index" and "field name subsection" because "field" is the more natural name to use in most places in the spec. Renaming everything to "composite index" felt dramatically worse to me.
50f6907 to
48f33c3
Compare
|
For what it's worth, I have yet to find any tangible connection between these declared index spaces and much else in the spec. A few things in validation explicitly handle indices. Many seemingly don't, e.g. struct fields! So I dunno. I tried to make the prose straightforward and clear at least. It should be obvious what an implementer should do. |
rossberg
left a comment
There was a problem hiding this comment.
I have yet to find any tangible connection between these declared index spaces and much else in the spec.
Do you mean in terms of how they are mapped to actual indices?
| \end{array} | ||
|
|
||
| .. note:: | ||
| All :ref:`composite types <syntax-comptype>` can be described by the field name subsection, not just :ref:`aggregate types <syntax-aggrtype>`. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
To be generic, you could just use plain idx (whose definition I just noticed was missing from the spec, but I just fixed that).
| 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>`. |
There was a problem hiding this comment.
Is there a reason not to extend this to result types? There are languages that allow naming results symmetric to parameters.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Yeah, I guess the name section isn't really for the benefit of annotating source language names.
|
Yes, in terms of how they are mapped to actual indices. In some cases they are explicitly attached to a context during validation, but seemingly not always (unless I'm reading it wrong). My impression is that it doesn't really matter that much, but that is why I'm playing a bit fast and loose with the terminology here. I don't see any other formalisms to extend in most cases. |
It is very natural to extend the field name subsection to include parameters for function types. The binary encoding for function types would be identical, and func types are already included under "composite types" in the spec anyway.
In this patch I have updated to keep the name "field index" and "field name subsection" because "field" is the more natural name to use in most places in the spec. Renaming everything to "composite index" felt dramatically worse to me.
Resolves #4.