Edition declaration

[stefnotch]

Should we require a statement like
enable wgsly.2024 in the main file? As in

• Document that this is some extended WGSL
• And have a version/edition of it. Which lets us change the syntax in later versions without breaking everything.

We can use the existing WGSL keyword for this https://www.w3.org/TR/WGSL/#extensions
We can either define it in the code, or in the wgsl.toml.

[mighdoll]

I agree that we should require the edition to be specified. When we have a second edition, we'll want to be able to link with libraries written in the first edition. It'd be nice to have forward compatibility in the syntax between editions, but that seems hard to guarantee - the underlying wgsl language may change expectations for future wesl editions.

Extending enable syntax to include wesl editions sounds good too. That'll be natural for wgsl programmers to understand. I'd suggest we use names in a similar format as wgsl features (lower case underscore separated), with a wesl_ prefix for each edition. (The enable line will be removed from the wgsl by the linker of course).

Including a year sounds helpful in the name, wesl_2025 might be our first stable edition. If we need a second stable edition in 2025, we might call it wesl_2025_Q3.

Before we've declared a first edition stable, I'd suggest we allow but not require e.g. enable wesl_2024_unstable. Perhaps we'll later want to identify particular unstable versions in the run up to stabilizing an edition, e.g wesl_2024_unstable_rc1.

For library .wesl, I guess we could require a well known file e.g. lib.wgsl in the root of the package and require the enable wesl_ in there.

For application .wesl, requiring that the enable wesl_ call be in the same file as the entry point seems reasonable. Because apps may have multiple entry points spread across multiple files, I think that multiple enable wesl_ entries should be allowed.

I'd suggest we require all application wesl to be the same edition. And each package should internally have a consistent wesl edition.

To support a library ecosystem, we should happily link if the app, package1, and package2 all have different editions. I imagine we'll aim to make wesl_2025 forward syntax compatible with future editions if we can. That'll help the programmer to keep things straight. But strict forward compatibility isn't required to make cross edition linking work, since we're transpiling everything anyway.

(In the future, when there are multiple wesl editions available, we could conceivably allow mixing multiple editions within the application package. But seems unlikely we'll need that.)

I'm guessing we'll be tempted to allow importing from raw wgsl files as well, at least in the application if not in libraries. I'm assuming wgsl can be distinguished from wesl by file name suffix metadata for now.

[mighdoll]

Should we make the enable clause required or optional for the first wesl edition?

Required is nice because:

• avoids future confusion about whether version unspecified wesl is accidentally or explicitly intended to first edition.

Optional is nice because:

• nothing needs doing right away

[stefnotch]

Required! Rust made it optional, and it led to accidents a few times. I'm not entirely sure if the latest versions of the Rust compiler will even go so far as to warning you when you leave it out.

[mighdoll]

Before we get to the first stable edition, I imagine we'll have a long period where we're trying WESL in apps and packages with early adopters. We can ask the early adopters to do a bit more work, e.g. expect that they'll want to make sure their tools, apps, and packages are all on the same wesl_unstable_x version.

What WESL version names should we use during that pre-stable period? Should we just number them sequentially?

Should we inject into the WESL some version information about the tools used? e.g. // packaged with wesl-rust 0.2.8