Allow both 'initial' and 'minimum' in memory and table constructors to keep it backward compatible

[aseemgarg89]

Please see the following test: https://github.com/WebAssembly/spec/blob/master/test/js-api/memory/constructor.any.js#L86

[rossberg]

The proposal already allows both, see the section on "Naming of size limits" in the overview.

[aseemgarg89]

I meant, we need to allow the following: new WebAssembly.Memory({initial:1, minimum: 2}); In this case initial should take precedence. Similarly, for table too.
Else, it's not backward compatible (the test I shared will fail if we put in the requirement that exactly one is present).

[rossberg]

Oh, simultaneously? So, IIUC, this test defines a generic proxy as a descriptor that returns any random property? I see how this would break, but I believe such a descriptor is (a) not useful in practice and (b) will break with pretty much any addition we could ever make (e.g., new optional fields in descriptors, because if present they'll need to have a certain type).

Hence I'm not convinced that it's worth taking backwards compatibility to such an extreme. With JS being as over-dynamic as it is, for any extension to an API, you can always produce a synthetic piece of code that would start to break or behave differently. If the criterion was that this must never happen even for contrived code then all JS APIs would be locked down for eternity. Not even the ES standard itself imposes such rigid constraints on its own libs.

That being said, I don't really mind either way. This question is probably worth taking to the CG. Would you be interested in putting it on the agenda for the next video meeting?

To unblock your work, I suggest implementing whatever semantics you prefer for the time being.

[aseemgarg89]

So, there was another option presented in the CG that we drop the keyword 'minimum' and just stick with 'initial'. While initial doesn't capture the full context, it'll skip the issue mentioned above and allow having duplicate keywords.