Make args_get require a capability

[Ericson2314]

https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-some-possible-changes.md#merging-read-and-recv recommends splitting things up, which is a good first step (code that doesn't depend on the environment part doesn't have that ambient authority). But going back to C's way is even better, where main is responsible for handing out access to the arguments. [I think rust's std made a mistake in doing something more like what the wasmtime first draft has now.]

[pepyakin]

On the other hand it might be unnecessary burden for WASI modules that doesn't take arguments. In that case, if a WASI host environment doesn't have notion of command-line arguments it still has to handle it somehow.

[PoignardAzur]

Yeah, but the way to handle that case is to not restrict function exports to a main function, so that the host environment can just import a function that doesn't take argv.

I agree that command-line arguments don't really seem like they deserve a syscall on their own, especially since hosts that otherwise implement wasi_core might not want to implement argv.

[wanderer]

But going back to C's way is even better, where main is responsible for handing out access to the arguments

This would conflict with using the wasm start function as mentioned in WebAssembly/WASI#19 since wasm start functions are not allowed to have parameters.

[wanderer]

@Ericson2314 also what would the alternative api look like?

[KronicDeth]

I assumed WASM module had start entry point without arguments because it was meant to work like shared library loading or DLLMain in Windows.

[sunfishcode]

This issue is similar to https://github.com/WebAssembly/WASI/issues/186.

[Ericson2314]

Indeed it is, thanks for making the connection.

[sunfishcode]

The new plan here is to make command-line arguments be arguments to the command entrypoint function, which turns out to be what the original comment in this issue suggested. Follow WebAssembly/WASI#509 going forward.