Remove requirement that function / builtin return values are always consumed

[ben-clayton]

Background:

#1413 proposed that call statements may only call a function or builtin with no return value, and that call expressions must be consumed by a statement. #1651 introduced this rule with the line:

If the called function returns a value, that value must be consumed either through assignment, evaluation in another expression or through use of the ignore built-in function

ignore() was added in #1587, and its original use was to allow an "escape-hatch" for cases where the user needs to call a function that returns a value, and doesn't actually want to use that returned value.

Since ignore() was added to the spec, it has found additional use for ensuring that binding points are referenced by a given entry point (this is possibly a Tint <-> Dawn implementation detail that needs spec clarification).

In #2115 we're discussing replacing ignore() with _.

---

We're now getting feedback ¹ from users that this original rule may be too restrictive.

For example: it's common to want to call atomicAdd() without using the returned "old" value.

I'm filing this issue so we can re-evaluate whether the rule to always consume a call return value is worth keeping.

[dneto0]

I proposed the original rule, as a way to add guardrails to the language. If those guardrails are bothersome, then I'm ok removing the rule.

[kdashg]

WGSL meeting minutes 2021-09-28

• DN: I wanted to add guardrails, but it seems to be causing heartache, so I’m fine dropping this requirement.
• RM: I also think it doesn’t need to be a requirement. Fine with not making it a rule so long as we can have a warning.
• DM: Let’s remove the rule.
• MM: Fine with me.
• MM: WGSL/WebGPU should have a mechanism to yield warnings.
• DM: To do a nice job, it’s nontrivial analysis to determine if function has side effects, and only warn when the function has no side effects.
• MM: No, keep it simple: function result not used. As long as we have the _
• JG: The bar is lower for warnings. If you don’t like the warnings, you have workaround with _ and can control warnings.
• DM: I don’t like false positives. Authors will turn them off, and they lose utility. Or complex control for turning off specific warnings.
• JG: They aren’t false positives (?)
• DM: They’re not false positives on atomics.
• JG: Leaves room to adjust warnings based on feedback. E.g. stop generating them for atomic functions.
• MM: Warnings are not standardized.
• JG: I think I proposed a mechanism for warnings,
• MM: Can write them to the console, as a last resort?
• JG: Shader module compilation information. https://www.w3.org/TR/webgpu/#shader-module-compilation-information
• Resolved: Remove requirement to consume return values