Interpreter issues with func.bind about function-references

[rossberg]

Doesn't a function need to contain its signature anyway? How else would you implement call_indirect -- or in the future, casts on functions?

[titzer]

For call_indirect, each table entry stores a signature id (call tag). Only table.set needs to look at a funcref value's signature in order to derive a signature id. For unbound functions, this can be computed from the code pointer of the function alone (up until we have type imports, in which case, it can be computed from the code pointer and the instance). For bound functions, the closure object can contain the number of bound arguments, thus the signature can be computed lazily from the function pointer and the closure object.

Related to #27, this is another example of statically derivable information becoming dynamic information.

I think it would be better to add an additional u32 immediate to func.bind which is the number of arguments bound. Even better would be a bitmask of which arguments are bound so that programs could do more than just left-to-right binding.

[rossberg]

Func.bind has been dropped from the proposal.