Myles and I think that this could be helpfully extended to vars, but we are 100% in favor of doing it for const even if the group decides not to do it for vars.

I agree that every expression in a valid WGSL program must have a single type, and that can be inferred bottom-up (#723).

I think we can go one step further. In #1289 (post-MVP mileston) I argued for even more abbreviated syntax.

So instead of

const a0 = b0.xzyw + s0.xzyw*sh.xxyy;
const a1 = b1.xzyw + s1.xzyw*sh.zzww;
const p0 = vec3<f32>(a0.xy, h.x);
const p1 = vec3<f32>(a0.zw, h.y);
const p2 = vec3<f32>(a1.xy, h.z);
const p3 = vec3<f32>(a1.zw, h.w);

We would have:

a0 := b0.xzyw + s0.xzyw*sh.xxyy;
a1 := b1.xzyw + s1.xzyw*sh.zzww;
p0 := vec3<f32>(a0.xy, h.x);
p1 := vec3<f32>(a0.zw, h.y);
p2 := vec3<f32>(a1.xy, h.z);
p3 := vec3<f32>(a1.zw, h.w);

That's even fewer characters to type on your keyboard. It also makes using 'const' the path of absolutely minimal resistance, and that's good.

It turns out I had seen this before, from Go. See https://golang.org/ref/spec#Short_variable_declarations
The differences are:

• In Go, it's used to declare mutable variables, rather than const
• In Go, you can have a list of variables on the left, as a destructuring assigmment. That's a good idea, but how about for post-MVP.

The ugliest part of my #1289 proposal was dealing with pointer vs. non-pointer. But since then we've chosen a direction where we have split (dual) types for "ref" and "ptr", and so there's no longer a confusion.

So we can cleanly do both : declare a pointer and declare a copied value:

       var age : i32 = 12;
       p := &age;        // same as      const p : ptr<function,i32> = &age;
       copyage := age;   // same as      const copyage : i32 = age; 

A clear followup is to infer the store type for a variable as well. It uses the same principle. Two possible syntaxes suggest themselves:

       var age = 12;  

or

       var age := 12;     //  It looks like we just removed the type from the standard form of the declaration.

@dneto0 I'm tempted to say "let's discuss := as a follow-up" since it blows out the scope of this PR and asks for much more time discussing the proper syntax. Just refining const is an easier thing to buy into right now.

In your (future?) proposal:

• would it replace const completely inside function bodies?
• if so, would you be able to specify the type if you want? something like `p : i32 = 1"
• wouldn't this complicate the parser? Right now, if it sees an identifier, it at least expects it to be known (i.e. assignment or function call). With your syntax, it's going to need more logic

Discussed at 2021-03-23 meeting

Agreed on the call to land this and follow-up with type inference for variables.

@dneto0 it's rebased now. Any concerns about the wording?

Previews, as seen at the time of posting this comment:
WebGPU | IDL
WGSL
_51088f5

Answering:

would it replace const completely inside function bodies?

It's important to allow the programmer to be very explicit. I would allow both:

    const a: i32 = 12;
    another := 12;

• if so, would you be able to specify the type if you want? something like `p : i32 = 1"

I would not allow that. If you want to be explicit, write the whole thing: const p : i32 = 1;

• wouldn't this complicate the parser? Right now, if it sees an identifier, it at least expects it to be known (i.e. assignment or function call). With your syntax, it's going to need more logic

No. It does not complicate the parser. The parsing into cases of call_statement, assignment_statement before checking for known-ness of the identifier. Adding my proposed case adds a "short_const_decl" case. It adds one more token into the follow-set of identifier: '(' for call expression, '=' for assignment, and adds ':=' for short-const-decl.

Does this mean types from functions will be inferred as well?
ie:

fn myFunction -> vec2<f32> {
    return vec2<f32>(1.0, 1.0);
}

const a = myFunction();

Does this mean types from functions will be inferred as well?
ie:

fn myFunction -> vec2<f32> {
    return vec2<f32>(1.0, 1.0);
}

const a = myFunction();

I don't see why not. The inference is still purely local: myFunction() will always return vec2, and it is declared to do so.

It's slightly more complicated because it's inferred from multiple expressions. I think it has less value and isn't very worth it.

Also now that I think about it, it could potentially make the code less readable.
const a = myFunction(); doesn't really show what the type of a is, you'd have to go to the function definition in order to find out.

Yes, there was no intention to infer function types. Let's not go into this territory, please :)

And what about trigonometric functions, texture samples and builtIn variables?

var angle : f32 = -atan2(a_particleVel.x, a_particleVel.y);
var uv : vec2<f32> = floor(30.0 * fragUV);
var texColor : vec4<f32> = textureSample(myTexture, mySampler, fragUV * 0.8 + vec2<f32>(0.1, 0.1));
var dims : vec2<i32> = textureDimensions(inputTex, 0);
var index : u32 = GlobalInvocationID.x;

Is there any clear rule when we should stop infer types? Because this thing works differently in Firefox/Chrome currently. https://github.com/austinEng/webgpu-samples/pull/121

Please do not get caught up in the status of prototype implementations just yet. We will be enforcing conformance via testing.

It's slightly more complicated because it's inferred from multiple expressions. I think it has less value and isn't very worth it.

Hm, I think when I said this I thought the suggestion was to infer the return type of functions. That we shouldn't do.
However, inferring the type of a var or const like const x = myFunction(); is consistent with the other rules, and it is already supported in the spec. I think local var and const declarations (including all of your examples @munrocket) never require type annotations.