Allow identifiers to start with _

[mr-ariel]

Identifiers are defined as /[a-zA-Z][0-9a-zA-Z_]*/

Which means, _my_var, is not valid, but my_var is.

Furthermore, a lot of languages, including JS, are ok with $ as well.

Any reason for constraining this?

[ben-clayton]

This decision predates me, but:

Preventing identifiers from being authored in WGSL with a leading _ allows the transpilers to generate underscore-prefixed symbols that are guaranteed to not collide with any authored identifier. Tint used to take advantage of this, but doesn't any more.

Also, C++ has some constraints around underscores:

• the identifiers that begin with an underscore followed by an uppercase letter are reserved;
• the identifiers that begin with an underscore are reserved in the global namespace.

Metal Shading Language is "a C++14-based Specification", and so would inherit these rules. WGSL -> Metal transpilers may catch and replace these reserved symbols, but a simpler option is to just forbid them in WGSL.

There's no technical reason why we couldn't have leading underscores in WGSL, but there is some effort in sanitizing these for the various backends.

[mr-ariel]

Isn't there a policy for adding new builtin function identifiers to WGSL later on?, like: new_builtin_function_x(....) or new_built_in_identifier/type,
is it the plan to use identifiers starting with _ for adding new functionality?

But even in c++, one can still create local or namespaced variables starting with _. I guess "reserved" is the right word though.

On transpiling, it is my use case (although a bit unusual), that I'm transpiling to WGSL and thus, I'm not able to retain variable names as they were originally written in LanguageX.
Although transpiling on any direction could be an use case, WGSL is still a language on its own.

Obviously, this is not a deal breaker for anyone, and not fan of underscores, but just an annoyance while working with WGSL, at least it did happen to me and I was surprised by it (enough to think it was a bug ;) ).

[ben-clayton]

The group really appreciate feedback, and your transpiling-to-wgsl case is probably something we haven't given a lot of consideration to. I'll try and get this added to the next weekly call, and we can see if there's any compelling reason to keep this restriction.

[dneto0]

Yeah, thanks for the feedback.

Isn't there a policy for adding new builtin function identifiers to WGSL later on?, like: new_builtin_function_x(....) or new_built_in_identifier/type,
is it the plan to use identifiers starting with _ for adding new functionality?

The intent is that new functionality will require the shader use an 'enable' directive. That's an explicit opt-in, and so new builtins or other type names introduced by the feature don't have to have special names.

Example:

// Explicit opt-in to a bag of features, including a 'super_accurate_square_root' builtin.
enable super_accurate_math;  


fn f(x: f32) -> {
  return 2.0 * super_accurate_square_root(x); 
}

See #600 for discussion about how we're thinking about expanding the language. That's where the 'enable' directive came, as a smallest-incremental feature that gets us what we really need.
A second thing we've discussed is namespaces, but there isn't much progress there. (#777 and also partly folded into #600).

About translating identifiers between languages, @ben-clayton is completely right.

Any general purpose translation will have to do some kind of sanitization and remapping. Another thing to think about: languages that have more general unicode identifiers. WGSL is headed in too, we just haven't got there yet in a first version.

[mr-ariel]

Thank you both for the replies!
it's great to see such a feedback for the smallest of details.

@dneto0, The enable directive sounds great!

And absolutely agree that transpilers have to do some extra work here and there.
I guess, that adds a bit more to the point that transpilers shouldn't be using _ to avoid colliding with other identifiers, but I do see why that makes it so much simpler to go from WGSL -> X

Again, thank you both!

[kdashg]

WGSL meeting minutes 2021-11-16

• DN: Reporter seemed ok with dealing with their transpilation case, after we explained our reasoning.
• DM: I think it would be better to allow this, especially since so many other languages allow this.
• RM: I think if we allow _ we should instead reserve _ _
• GR: We could always continue to reserve $
• AB: Conflicts with frexp, modf results that have user-unnamable structs. Would have to change those.
• ...
• JG: It’s a papercut, but we can ship with it and things will work fine. Can we postpone discussion?
• Retarget for post-v1
• DM: Can we do a census on our corpus for this pattern?
• MM: I can do that
• MM: Just ran it, on 2000 files, 800 lines appear to use this pattern
• DM: This sounds important then
• JG: People use it, but our question is not “will people use it if available”, but rather “will people be sad if they can’t use it”, which is subtly different.
• JG: Anyone can re-add this to a meeting agenda if they want to re-discuss this.

[dneto0]

We're hearing further feedback that this is a pain.

I'll post a PR that:

• allows _ as a proper prefix. (We need _ for phony assignment)
• disallows two underscores as a prefix, and renames the frexp,modf structs to use two underscores.