#Designing Enhancements for WESL

This section discusses some general design guidelines for creating new shader language enhancements.

#Goals

We’re aiming to create a modestly improved, practical variant of WGSL. WESL should feel like WGSL with a few things added.

#Priorities

We’re aiming to prioritize WGSL enhancements that are:

important for community projects
feel natural to the WGSL programmer
not too difficult to integrate into community tools

We’re guided by demonstrated needs in community projects.

We’re willing to work harder on tools to make the experience feel more natural to the programmer.

#Who are WESL Programmers?

Vanilla WGSL programmers first. Our programmers will learn WGSL before learning our extensions. We should be additive to WGSL, not change semantics.

Part time shader programmers. Our programmers will have to relearn any intricacies we introduce over and over again, so keep it simple.

Medium size teams. Our programmers work on projects ranging in size from tiny programs up to teams of few dozen programmers.

General programming knowledge. Our programmers will likely know JavaScript/TypeScript or Rust, though not both. They’ll also have been trained in at least one other popular language like Python, Java, or C++. Overall, we can expect that our programmers will know general concepts available in most mainstream languages, but we can’t count on them to know the details from any particular language other than WGSL.

#Syntax from Rust and TypeScript?

Avoid trying to imitate a TypeScript or Rust language feature syntactically unless it can fully match the source language semantics. If it looks just like a Rust or TypeScript feature, programmers will expect it to work like the source language.

But fully matching the source language will often be impossible in WGSL, or undesirable for complexity reasons. And a feature that looks the same but works differently will be hard for programmers to keep straight in their minds.

Aim for simple instead of imitative.

#Stable Editions

We want community tools to support all stable editions, and we hope to support stable enhancements for years. Before we include an enhancement in a stable edition, we’ll want it to be polished, proven in use, tested, and well documented.

#Experimental Enhancements

The tools we’re developing (e.g. the linker/transpilers) will be a good base to build out new enhancement ideas. It should be easy to implement and try out new WESL enhancements on local WESL projects.

Experimental enhancements aren’t intended to be supported across tools, and don’t need to be compatible with other experiments. As experiments move toward stability we’ll move experimental enhancements into more tools behind a feature flag so more projects can try them.

#Words and Reserved Words in WGSL

WESL features use reserved words from WGSL (e.g. import) so that they can serve as true proposals for WGSL adoption. WESL maintainers are technical advisors to the W3C WebGPU committee, and we design features with the goal of minimal divergence from a possible future WGSL.

We avoid changing the meaning of existing WGSL keywords. Any differences WESL introduces are erased during transpilation to WGSL, and we don’t want to confuse programmers by unexpectedly changing the meaning of a keyword.