Andreas Rossberg

`maximum` and `current`/`length` sound good to me, but I'm less convinced about `initial`. In V8 at least, we don't even remember that information. What would be the use case for...

@jfbastien, re consistency: the right feature to look at would be neither of the above IMO but the "resizable limits" in the import/export types of memories/tables, because that's pretty much...

@domenic, we need a name that works consistently for both memories and tables, and unfortunately `byteLength` does not. @jfbastien, how about `size`?

@jfbastien, because tables share the exact same limits properties, so should expose them in a consistent manner. If `length` is verboten, then we'll have to find another name for it...

Tables can grow in the same way as memories, and they also have an initial size, a current size, and an optional maximum size (see e.g. the use of `resizable_limits`...

Well, in the API, we already have the same symmetry in the Table vs Memory constructor arguments (both taking an object with `initial` and `maximum` properties. And it is present...

We deliberately chose to make this post-MVP, so we should not rush it into the MVP spec now all of a sudden. There is a bit of a design space...

We could relax the call restriction in initialisers, e.g., by only allowing calling imported functions, similar to how we only allow reading imported globals. That seems natural, even more so...

IIRC, the CG recently discussed the feasibility of trying to keep the design docs up to date, and it wasn't clear how to do that unless we can find a...

> Does this apply even to docs mentioned above like Binary Encoding, Text Format, Semantics that live in the spec repo now? Yes, I think so. Not everybody is prepared...