Text format for shorthand shared functions

[abrown]

The current text format only allows specifying a shared function with an explicit type index:

(type $shared (shared (func)))
(func (type $shared))

I had thought (and so have others) that it might be nice to have a short-hand form for writing shared functions when printing WAT. There are some advantages to this: easier to read WAT, easier to write WAT manually, consistency with unshared functions, etc. But, for now, we have left this out because it's unclear how to best express this:

• (shared (func ...))?
• (func (shared (param) (result)) ...)?

I'm opening this issue to track this for discussion and for future users who are interested in why things are the way they are.

[tlively]

Syntactially, the type use in the function includes the explicit (type $f) declaration, if any, as well as the (param ...) and (result ...) declarations, if any. It is these elements taken together that resolve to a particular declared or new function type, so any new information used to resolve the type should be added here. Possibilities include:

1. (func $foo (shared (param ...) (result ...)))
2. (func $bar shared (param ...) (result ...))

If we want to allow shared to be present when (type $f) is also present (just like we do for param and result), then that could look like this:

1. (func $foo (shared (type $f) (param ...) (result ...)))
2. (func $foo shared (type $f) (param ...) (result ...))

It would be an error if $f were not shared in these cases, just like it would be an error if the number or types of parameters or results do not match $f.

On the other hand, the fact that type uses can define new types is one of the most complex and unfortunate parts of the text format, and there is no precedent for letting them define new non-MVP function types such as non-closed function types or types in nontrivial rec groups. I would be happy to avoid extending this feature of the text format.

[alexcrichton]

As the "other" linked above I can chime in here to say that I'd be fine with the suggestion to explicitly not add this sugar to the text format. I don't have a horse in the race either way and mostly figured it'd be good to have a decision on the record one way or another, but either way is fine by me.

If we go the text route I'd put a vote in favor of (func $foo (shared (param ...)) ...) to help separate it from instructions such as (func $foo (shared) unreachable).

[rossberg]

I think we should allow/require shared. If not, it means that in a shared memory setting, you'll have to define and reference all function types manually and repeat yourself all the time. By the same token we considered that too tedious for unshared functions, we would likely consider that too tedious for shared ones. It's also arguably a bit inconsistent to derive some parts of a function's type from the type definition but not other parts.

@alexcrichton:

If we go the text route I'd put a vote in favor of (func $foo (shared (param ...)) ...) to help separate it from instructions such as (func $foo (shared) unreachable).

Since instructions can be parenthesised as well, I don't see how the extra brackets buy anything in that regard. I find wrapping them around the params/results somewhat odd in this instance – to me that would suggest that it applies to the parameters, not the function as a whole.