I know that the idea has come up in the past of relaxing the exactly-two-import-names requirement in WebAssembly. It occurred to me this morning that the resolution of #22 actually conflicts with the likely text syntax for a non-compact import with just one name:
(import "foo" (func (param i32))) ;; one name (parsed as empty compact-2 group today)
(import "foo" "bar" (func (param i32))) ;; two names
(import "foo" "bar" "baz" (func (param i32))) ;; three names, etc.
This is awkward, and I wish I had thought of this before phase 4! I realize that we don't actually have even a phase 1 proposal for multi-level imports (anymore), so perhaps this is a corner worth painting ourselves into. But I figured I should raise this for discussion.
The text syntax is the thing most directly affected by this; the binary format is basically fine (see below). We could leave this multi-level import syntax open for ourselves by reversing our decision in #22 and forbidding empty compact-2 groups (and possibly compact-1 groups if we want to be consistent in that regard). Or, perhaps multi-level imports could just choose different text syntax in the future, e.g. (import (path "foo" "bar" "baz") ...).
As for the binary format, multi-level imports could probably be signified by <empty name> <empty name> 0x7D vec(<name>) externtype. I wouldn't consider this any kind of conflict with the compact import section proposal, because even if compact imports did not exist, this kind of workaround would be necessary just like it was for compact imports.
I know that the idea has come up in the past of relaxing the exactly-two-import-names requirement in WebAssembly. It occurred to me this morning that the resolution of #22 actually conflicts with the likely text syntax for a non-compact import with just one name:
This is awkward, and I wish I had thought of this before phase 4! I realize that we don't actually have even a phase 1 proposal for multi-level imports (anymore), so perhaps this is a corner worth painting ourselves into. But I figured I should raise this for discussion.
The text syntax is the thing most directly affected by this; the binary format is basically fine (see below). We could leave this multi-level import syntax open for ourselves by reversing our decision in #22 and forbidding empty compact-2 groups (and possibly compact-1 groups if we want to be consistent in that regard). Or, perhaps multi-level imports could just choose different text syntax in the future, e.g.
(import (path "foo" "bar" "baz") ...).As for the binary format, multi-level imports could probably be signified by
<empty name> <empty name> 0x7D vec(<name>) externtype. I wouldn't consider this any kind of conflict with the compact import section proposal, because even if compact imports did not exist, this kind of workaround would be necessary just like it was for compact imports.