This is a proposal to address #1155 .
Aligns well with #1171.

We should consider:

• putting the "in" variables into the arguments of functions
• making the "out" variables to be result values of the functions
• leaving the resources to be in variables

Here is how it may look like:

[[group(0), binding(0), uniform]] params : SimParams;

struct VertexInput {
  [[location(0)]] texCoords : vec2<f32>;
};
struct VertexOutput {
  [[builtin(position)]] position: vec4<f32>;
  [[location(0)]] colour : vec4<f32>;
};

[[stage(vertex)]]
fn vertex(input: VertexInput) -> VertexOutput {
 ...
}

[[stage(fragment)]]
fn fragment(
    input: VertexOutput,
) -> [[location(0)]] vec4<f32> {
}

[[stage(compute)]]
fn comp_main(
  [[builtin(invocation_id)]] gl_GlobalInvocationId : vec3<u32>,
) {}

This is how we can return more than one value:

struct FragmentOutput {
  [[location(0)]] mrt0 : vec4<f32>;
  [[location(0)]] mrt1 : vec4<f32>;
  [[builtin(sample_mask)]] sampleMask : u32;
};

[[stage(fragment)]]
fn fragMRT(
  [[builtin(position)]] pos : vec4<f32>
) -> FragmentOutput {}

The in/out variables and builtins can be specified either directly as argument (or return values), or put into a struct. This largely follows the HLSL (see example) and MSL (see example) shaders.

In the specification, we can say that struct layouts can be one of the 3 different kinds:

• interface layout: for the input/output structs. Every field has to have either [[location(xxx)]] or [[builtin(xxx)].
• block layout: for host-shareable structs. Some of the fields can have [[span(xx)]
• internal structs: no decorations are expected on the fields (but can still be on the types, etc).

Note: returning tuples may improve some of the cases, but it's not required in this proposal, can be considered after MVP.