Tough issues

[stefnotch]

• use a::b::c; is problematic, because I cannot tell if it's "import function c from module a/b.wgsl" or if it's "import module a/b/c.wgsl"
• Importing WGSL packages from cargo is tricky, what is the ideal option there? (The node_modules folder is much easier to work with.)
  • For example, we could say that it's up to Rust WGSL linkers to understand Cargo. The Javascript WGSL linkers do not have to understand Cargo, they would instead understand npm. And so on.
  • To use a WGSL package from another ecosystem, you just copy the source code/republish it in the correct package registry for the ecosystem.
• Entry points and pipeline overridable constants need mangling
• Warn people that pipeline overridable constants and #defines are globals! So if a module gets imported twice, it shares the global. There's no way of saying "include foo::math with f32 support and then separately import foo::math with f64 support".

[stefnotch]

Regarding mangling, this is what we currently have

• Mangling everything and exposing them that way. Names would look like bevy__pbr_lighting_some__constant. Name mangling becomes part of the specification.

• Requiring that everything is re-exported from the root module. Names would be short. Potentially very verbose and repetitive root modules.

• Generating a bindings map. It would look like { "bevy_pbr::lighting::some_constant": "mangled name goes here" }. Bindings map is required for using the generated .wgsl.

• each linker exposes a small library to mangle/unmangle names according to linker specifics from ncthbrt

[mighdoll]

re: mangling, another option:

• allow the programmer to optionally set the public name visible from host code in any .wesl module. e.g. @public(myPkg_backgroundColor).

[mighdoll]

How 'bout we make new issues for each of the remaining tough issues listed above? (and close this one).

[stefnotch]

Sounds good