allow imports from .wgsl (not just .wesl)

[mighdoll]

wesl code will coexist in the community with vanilla wgsl code for the foreseeable future. To enable easy interop with wgsl, I'd suggest we allow wesl imports to import from vanilla wgsl modules.

A user should be able to take a wgsl file containing a utility functions (e.g. color space conversion), add the wgsl file into their project and immediately be able to import one or more of the utility functions into their wesl application with no editing of the wgsl required. Another scenario, users with existing wgsl projects would be able to incrementally move their wgsl files to wesl with higher confidence since no editing is strictly required.

It would be nice if a wgsl code module is valid wesl, in which case supporting this feature requires no additional implementation effort. But several features we've discussed (e.g. module private by default, required module paths, etc.) would break that assumption.

If wgsl is not valid wesl, we could still teach linkers, language servers, and other tools to understand wgsl as well as wesl. Some additional complexity would ensue of course.

[mighdoll]

Shall we spec that WGSL is valid WESL, and then close this?

[stefnotch]

I think this is completed? Or should we explicitly state that WESL is a strict superset of WGSL somewhere in the Readme?

[k2d222]

from the updated imports spec:

Linkers are allowed to fall back to .wgsl files when a .wesl file cannot be found in user code. Published libraries will only contain .wesl files. Thus, linkers should change wgsl files to wesl for publishing, if applicable.

My only question/doubt is should we handle .wgsl files differently than .wesl files? (i.e. should we allow WESL extensions). I guess we should just treat them like WESL code, because hey let's avoid needless extra work if possible ;)

If we agree let's close this

[mighdoll]

Let's consider changing that spec line on tools rewriting .wgsl to .wesl in libraries. It sounds like it breaks our marketing promise to support wgsl..

@stefnotch has suggested elsewhere that perhaps libraries don't need file paths at all (and should use module paths), in which case the issue is moot since there won't be file paths anyway.

If there are file paths in libraries (perhaps we'll want them for error reporting), then I fear that rewriting the publishers file suffixes will be confusing to users. It will require an extra fs lookup in resolving .wgsl libraries, so there'd be some minor performance cost.

[mighdoll]

Or should we explicitly state that WESL is a strict superset of WGSL somewhere in the Readme?

+1 for that! It's a great thing to explain for ongoing new adoption. Your WGSL code just works.

Maybe not quite 'strict' on superset I suppose. Somewhere lower down, we should also discuss the minor differences when bringing wgsl into a wesl project. Everything is the same in the root module, but porting a wgsl module, you'll notice some minor differences (e.g. const_assert in unused modules, #65, etc.).

[k2d222]

I fear that rewriting the publishers file suffixes will be confusing to users

ah yes. I think a package should contain the 'untransformed' source code alongside any transformed code (like what you did with random_wgsl).
There might be use-cases for transforming source code before publishing the package, e.g. bundling all files into a single one (and perhaps erase the file paths per @stefnotch suggestion). In this case I imagine we'd produce some form of sourcemapping and ship the source alongside the transformed code.

Was there another reason to rename .wgsl to .wesl?

Or should we explicitly state that WESL is a strict superset of WGSL somewhere in the Readme?

+1 for that too

[stefnotch]

Okay, I'm convinced. Let's take that out of the spec, and let's plan for packages to have both

• the untransformed code
• the ecosystem specific, transformed code or glue. I imagine that it's nicer for both the JS/Rust world if we can ship a .js/.rs file with the shaders that people can just import the way they're used to.

[mighdoll]

agreed, update spec and close issue

[stefnotch]

Linkers should fall back to .wgsl files when a .wesl file cannot be found.

is what https://github.com/wgsl-tooling-wg/wesl-spec/blob/main/Imports.md says today