[RFC] impr: Weak type checking on binary expression operands

It all comes down to this list:

const parenthesizedOps = [
  '==',
  '!=',
  '===',
  '!==',
  '<',
  '<=',
  '>',
  '>=',
  '<<',
  '>>',
  '+',
  '-',
  '*',
  '/',
  '%',
  '|',
  '^',
  '&',
  '&&',
  '||',
];

Currently, we don't really check the types of the operands. For example:

 const eq = tgpu.fn([Boid, BoidOnSteroids])((x, y) => {
  'use gpu';
  const r = x === y;
});

will happily compile.

Right now, we rely on the fact that wgsl compiler will throw a descriptive error.
I was fine with this approach for a long time, but...

No 1.

const x = d.vec3f();
const y = x;

const eq = () => {
  'use gpu';
  const _r = x === y;
};

The above function will inline true in place of the equality comparison.
However, if x and y were runtime known values, the return type of the function would have been d.vec3b (since that't how wgsl treats == between vectors).

No 2.

Delegating error handling to the wgsl compiler quickly makes things difficult to debug.
For instance, out ternary operator polyfill uses select underneath. It does not check if the condition operand can be converted to a boolean, it assumes that typescript will prevent users from doing so.

While typescript sometimes catches this, an equality comparison between runtime known vectors results in boolean vector. This completely changes the behavior of select. Furthermore, users end up with no idea why there is a type mismatch in a select expression they didn't even use.

No 3.

Conceptually, the wgsl generator should always produce valid code.

Proposition:

Strictly check operand types to closely match the wgsl specification.

Start by tracing how binary expressions are type-checked and generated, then inspect the ternary operator polyfill's use of select. Compare operand rules with the WGSL specification and the examples in the issue. Done means invalid operand combinations are rejected before generation and diagnostics no longer surface misleading select errors.