I'm getting a bit confused by these rules. So the first rule says that when I type my_vector, where there is var my_vector:... in scope, the result of this is a pointer to vector. So, how can I then do const other: vec4<f32> = my_vector? The left side is a value, the right side is a pointer to a vector, according to these rules.

What does "formal" mean in this context?

We haven't written the section on functions yet.

I can add a TODO to define that.

This is a bit unclear. Are we trying to say that the bit pattern representing these pointers is the same? Or something else?

The pointer values are the same, i.e. they reference the same underlying storage. It's an implementation detail as to what the bit pattern of the pointers are.

It reads as "the value of the parameter is the same as the pointer value", roughly, which is what confuses me.
Perhaps, it's the "value denoted by" semantics that I'm misreading?

this is a bit confusing, since we are no longer being able to reason about an expression type of "x". So it make the rules more complex, and goes against limited inference of types that we want to get eventually.
was it considered to use &x syntax instead?

When you add address-of, you now have to distinguish between l-value and r-value.
When I look at a variable in isolation, I don't know if it's being used as an l-value or r-value until further out in nesting. I have to defer evaluation (in my head) until I see or don't see a & operator used as address-of. Also & is the same name for a binary operator.

Example
&a.b.c.d[12];

In this example I would like to evaluate from what looks like the inside out (right to left) but I don't know if I'm dealing with pointers or values until I get to the very left. There's an inherent ambiguity there just the same.

C and C++ also have an arrow operator to step down into a pointer-to-composite: ->

In the current design you stay in the pointer domain for as long as possible, i.e. dereference (for load) only when necessary.

When you add address-of, you now have to distinguish between l-value and r-value.

Right, and we have options there. I.e. we could even go with "store(my_pointer, value)", given that pointers are not widely used. This wouldn't affect variable assignments, obviously, since variables are not the pointers.

In this example I would like to evaluate from what looks like the inside out (right to left) but I don't know if I'm dealing with pointers or values until I get to the very left. There's an inherent ambiguity there just the same.

Is this really a problem to parse? Both C and Rust have "&" for the address.
I haven't implemented it, but it seems like the "&" is clear based on the parser context. if an expression is expected, then "&" is an address. If other things are expected, then "&" is a binary operator.

@litherum was that a reaction to "store(my_pointer, value)" (which I don't think is really necessary), or to having "&" in general for taking a pointer?

I guess this load rule is what confuses me most. I believe this complexity is unnecessary, and pointer construction could be more explicit, without ruining the type inference.

You pay either like this, or by not knowing if you have an l-value or an r-value.

I wonder if l-values are going to be a problem for us, really. Unlike C, we don't need the "=" to produce a result, we don't need to support "a = b = c", etc. So for WGSL, supporting syntax like "*pointer = value;" could be trivial:

• in the statement context, if it starts with "*", we are looking at the assignment (i.e. the l-value would follow).

Are there hidden pitfalls?

Small update: I we are already tracking L-values versus R-values in WGSL frontend. I'd assume Tint does so, as well. I.e. when you parse "something.other = value", the parser needs to understand that "something.other" is an L-value. So de-referencing pointers with "*" doesn't introduce any more complexity in here than we already have.

So, multi-letter swizzle would be a validation error?

No. It's forced to be a dereference (load), followed by swizzle.

How does that work with the pointer? I'm saying:

var a : vec3<f32>;
const b : ptr<function, vec2<f32>> = a.xz;

would be a validation error, yes? Or, are you saying that a.xz loads into a temporary and we take the address of the temporary?

Yes, that's a validation error.

It's a validation error because you can't form a pointer type from the right hand side.
You would like to use a rule from section "Component pointer from vector pointer" But that only has rules for a single letter after the dot.

Right, I think we should add a brief 'multi-letter swizzles are a validation error' just to make that clear in the doc.

By the way, in Metal, you can't take a pointer to a member of a vector, even if that member is a single field.

No. It's forced to be a dereference (load), followed by swizzle.

We haven't written the section on functions yet.

I can add a TODO to define that.

The pointer values are the same, i.e. they reference the same underlying storage. It's an implementation detail as to what the bit pattern of the pointers are.

Yes, and more. Composite type covers structure, array, vector, matrix.

You pay either like this, or by not knowing if you have an l-value or an r-value.

MSL doesn't support this.

Closest I could find in the MSL reference is:

• A pointer or reference to a vector with swizzles is an error:
float4 pos = float4(1.0f, 2.0f, 3.0f, 4.0f);
my_func(&pos.xy); // This is an illegal pointer to a swizzle.

But that's a multi-letter swizzle.

OpenCL C is more direct about the single-letter case:

It is illegal to take the address of a vector element and will result in a compilation error. For example:
float8 vf;
float *f = &vf.x; // is illegal
float2 *f2 = &vf.s07; // is illegal