Include table.fill and table.grow

[rossberg]

No description provided.

[lars-t-hansen]

Not sure what you're intending here. The bulk copy proposal has neither table.fill nor table.grow; the present proposal seems to introduce the former and assume the existence of the latter. (Not a big deal, just observing this while passing by.)

[rossberg]

@lars-t-hansen, yes, this is just a tracking issue to include them into this proposal properly. Neither of them is currently in the draft spec or interpreter, even though fill is mentioned in the overview.

They cannot be added independent of this proposal because they need reference types. Assuming that we have bulk ops before reference types this would be the right place to fill them in.

[lars-t-hansen]

Note to readers: to be forward-looking to non-nullable reference types, table.grow should take a value to use for the new elements: (table.grow $table delta init-value)

[lars-t-hansen]

Since memory.grow returns -1 on failure to grow we should probably do the same for table.grow.

[lars-t-hansen]

Note to readers: to be forward-looking to non-nullable reference types, table.grow should take a value to use for the new elements: (table.grow $table delta init-value)

If we leave funcref out of the reftypes proposal for now (as discussed + agreed at the CG meeting in Lyon) then the requirement for an initial value for table.grow leaves us with no way of growing a table-of-anyfunc, for the time being - unless we want to special-case nullref in some (probably hacky) way, probably not very desirable. The way out of that could be eg table.grow_default, which uses the default value for the type, in the same way struct.new_default is proposed for the GC feature. Somehow I suspect grow_default does not have a lot of long-term value however.

Leaving funcref out is supposed to be a way to focus the proposal more tightly on features that can ship more quickly, but leaves some interesting holes. table.copy can copy function values, but table.fill, table.set, table.get, and table.grow can't operate on function tables because we don't have expressible function values.

[alexcrichton]

@lars-t-hansen could it perhaps be a validation error (temporarily, until subtyping is good to go) for any table instructions to operate on an anyfunc table?

[lars-t-hansen]

@alexcrichton, Sure we can do that and it's come up as a solution several times. My main worry about that is essentially bureaucratic: Will an incomplete implementation count toward bringing the proposal to shippable + standardized state / stage 4? I'd like to actually ship something in Release and move it into the official spec so that people can start depending on it; it does nobody any good if it sits behind a flag or on sundry nightly channels.

[lars-t-hansen]

table.grow and table.fill are both in the overview, spec, and reference interpreter, and I think funcref is included in ref-types still (and we've implemented them), so i think this is done.

[rossberg]

Yes, I think so. Closing. (Thanks for going through the issues!)