We talked about this with @dneto0 some more. Here are my conclusions.

How removing would affect all the parties:

implementations: we are in agreement, I believe, that they are not affected. If WGSL doesn't have Void, the type system of Tint or Naga can still have it, and visa versa.
users: the concern was that -> void would be explicit. I believe the lack of return type is equally explicit, and in Rust we have a situation where nobody ever specifies -> ().
specification: it doesn't appear to me that the pretense of Void makes the spec any clearer. Removing it in Remove the void type #1460 saves about 15 lines.

Additional concerns:

type system purity: the concern was that having each (code) statement and expression with a type makes up a good type system. First of all, this may very well be an implementation detail, as I explained above. Secondly, this isn't a case in any other shading language. Even the SPIR-V, which arguably the purest of all, doesn't have the "OpStore" instructions (analogous to our assignment statements) with an associated result type. Therefore, even if we have "void", we'd get the function call statements having types, but still not the assignment statements, so it wouldn't make the spec more regular.
compatibility: we can always introduce void later, but we can't remove it. If we introduce tuples in the future, we can also consider () to be what we currently call void, similarly to Rust. Not having Void in the spec today would leave this door open.
generic code: the concern was that when we get generics, it would be nice to have them be general over void and non-void types. I strongly believe we can cross that bridge when we get there, by potentially introducing void or something else. Keeping it right now seems premature for this.
code generation: the concern was that if the user of the API generates WGSL code, they would benefit from the regular structure of always returning a type. I think this is far-fetched. It very much depends on what is the source language for code generation (does it have void?), and I think the generation logic would have to check for void specifically at the return sites anyway, since they look different.

Overall, I'm not finding a good excuse to have the Void with us.

Edit: expand the "compatibility" and "OpStore" sections.

Follow-up: Using the void type #743

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions