Dean	:	Chair
Dan Sinclair and everyone	:	⌨️ Scribe
Google Meet	:	Location
https://webgpu.dev/wgsl	:	Specification
WGSL Issues	:	Open Issues
Marked Issues	:	Meeting Issues

PR Burndown

• No explicit grammar for decorations (#689)
• Allow e.g. if (cond) break/continue/return/kill; without brackets. (#705)
• Add bit-complement operator ~ (#727)
• Introduce Subgroup Operations Extension (#954)
• Add script to extract grammar from WGSL spec (#1062)
• Int and float literals don't include leading minus (#1092)
• Introduce operator precedence table (#1111)
• describe texel formats (for storage texture types) (#1112)
• Add FAQ for direction on shader language (#562)
• Update Goals section of spec (#588)
• Update goals section (#599)
• WGSL FAQ (#687)

---

WIP, the list of all the people invited to the meeting. In bold, the people that have been seen in the meeting:

• Apple
  • Dean Jackson
  • Fil Pizlo
  • Myles C. Maxfield
  • Robin Morisset
• Google
  • Dan Sinclair
  • David Neto
  • Kai Ninomiya
  • Ryan Harrison
  • Sarah Mashayekhi
• Intel
  • Yunchao He
  • Narifumi Iwamoto
• Microsoft
  • Damyan Pepper
  • Greg Roth
  • Michael Dougherty
  • Rafael Cintron
  • Tex Riddell
• Mozilla
  • Dzmitry Malyshau
  • Jeff Gilbert
• Kings Distributed Systems
  • Daniel Desjardins
  • Dominic Cerisano
  • Hamada Gasmallah
  • Wes Garland
• Joshua Groves
• Kris & Paul Leathers
• Lukasz Pasek
• Matijs Toonen
• Mehmet Oguz Derin
• Pelle Johnsen
• Timo de Kort
• Tyler Larson

---

• MM: If I remember correctly, doesn’t change set of acceptable programs?
• JG: Right. Looks like just nits to fix up. Will push those across the line offline.
• MM: All in agreement this should merge? DM has comments?
• DM: Talked to JG and figured it’s fine. Main confusion was associating grammar with what’s in IR. Breaking that association it’s fine for hte grammar to be more abstract.
• MM: On more abstract grammar, thinking of doing more of these types of pull requests. Removing specific terms from the grammar and replacing with IDENT. If we did a few, would people think that’s a bad idea? Or just go ahead and do it and discuss.
• JG: Case by case feelings. Make some cases.
• MM: Ok. May also not do it. PRs that don’t change the set of acceptable programs is low priority.
• DS: Also good with merging once nits are fixed.

• JG: Waiting on me. Concerns about what this does to the grammar. Having this now is not worth it if it makes the grammar worse but would be a nice quality of life. Can handle later. Low priority
• MM: Confused similar to DS about if(cond) break; which doesn’t need {}’s but if(cond) i = i+1; requires braces.
• JG: This opens the ability to omit for only a few things in an opinionated way. Says we don’t want arbitrary statements outside brackets, not for grammar but as language designers. Rather than saying need brackets all the time, we may want to say early outs can skip the brackets.
• MM: Two concerns with that idea. 1- sets up dangling else problem which is unfortunate. 2- allowing this brace less conditionals makes clarity confusion around if conditions with comments and newlines and breaks. For those reasons, requiring braces would be good.
• KN: Wasn’t the syntax meant to express conditional breaks and returns? Without the braces, not creating new control flow. Conditional continue break or return. Else is not allowed as it doesn’t make sense on a conditional break.
• MM: Does that mean if (cond) break; else other; would require braces
• KN: That was my intuition
• MM: If that is true, that makes the language harder as sometimes the {}’s are required and sometimes optional. Seems like it would make it difficult to write.
• JG: Wouldn't describe that as the goal. Goal, at the core, is a style I use and find it useful and find it nasty to do if (foo) { return false; } vs one line.
• MM: Does the ability of having on one line but with {}’s help achieve the goal.
• JG: I think you can do that already.
• MM: Yup.
• JG: Goal, for a certain class of statements relax the bracket requirements given all of us are writing the code in syntax/keyword highlighting editors. It’s obvious you get if control flow. Not a big deal it isn’t in brackets.
• DN: What about break if(cond)
• JG: WOuld resolve dangling else issue or other ways would fix that
• MM Didn’t we already resolve that proposal
• DN: Yea, but at the same time we said braces everywhere.
• JG: Decided that other thing for different reasons. This is quality of life/ code style
• MM: If this proposal was accepted and wanted an if else do I need braces? What situations need / don’t need?
• JG: Current grammar if (foo) return false else return true;
• MM: Right, then dangling else problem.
• JG: Right. What’s most important here is not ability to have control flow statements in else branches be one line, but the core is to be able to do if (cond) break; if (cond) return; Because they’re control flow most style guides require not having an else after if control flow. Goal was to if control flow and not involve in else’s. Should look how that might be done in the grammar and remove the dangling else problem. Should avoid, as the valid tokens after if cond { are either ( or break or return or kill or continue.
• KN: +1 to postpone after MVP.
• JG: Don’t need to talk about this now. Waiting on me to address concerns.
• MM: Will record concerns in issue

• RM: as far as I can tell, only issue is if we should use ! as we can tell from the type or if we should follow c and have ! and ~. In favor of having both in terms of clarity and readability without having to look at the type what operation we’re doing. Additionally already the c and c++ default and other languages.
• DM: Don’t think it’s unclear if we use the same symbol. No implicit conversions don’t need a separate symbol
• JG: Coming from rust that’s clear. From outside rust it’s unclear and surprising. Maybe people can work out what’s happening but it will be surprising. When taking bit complement, and we use the ~ to a casual reader who isn’t familiar with rust or us they’ll see the ! and think logical negation
• KN: Agree with JG:
• RM: Inversely, someone doing logical negation and uses ! on an integer in an arithmetic context then with ~ we can return error and ask for conversions. Otherwise we’ll silently do bitwise negation which isn’t what they want and is frustrating for them.
• DM: Can always do as integer on argument to make it clear it’s an int and not bool
• JG: More willing for the same symbol if it was ~ and defined ~ on bool to be logical negation. Going the other way is an issue
• KN: Agree that makes more sense and lines up with other languages where you can do ~ on bool.
• JG: Still like logical not as it’s common to work with integers mostly and automatically convert to bool and take the logical negation. Requesting cast to bool and do bitwise complement to do logical negation feels too formal and verbose
• DM: Are you suggesting implicit conversion?
• JG: FOr logical not integer
• DM You want logical not on integer to make a bool
• JG: Yes.
• DM: More discussion needed then - I don’t want that. Don’t think it’s needed
• JG: Agree that it is not needed
• DN: Are we rationing the symbols used? Why not use a symbol?
• JG: Rust does it this way
• DM: Rust has complaints on the number of symbols
• JG: Orthogonal as folks don’t say that about c or c++
• KN: Difference, this is very standard and symbols do different things. Reducing # of symbols isn’t helpful if it’s 2 functionalities on the same symbol
• DM: Why say they’re different, just bit negation
• KN: Just if you think a bool is 1 or not. Which most do not.
• JG: See a bitwise negation on a bool expert true. If I see ! next to integer expect cooresion to bool and logical negation.
• DM: That’s c experience which has implicit conversion which we don’t have. WGSL is closer to Rust
• JG: I have 10 years of experience with other languages and you’re asking everyone to adopt a new thing Rust has. Rust innovated and that's cool but I wouldn’t have done that and I don’t think we should do that here. From a readability standpoint we want it obvious what the code is doing and not ask folks to memorize a new symbol meaning. Asking to internalize in WGSL and not JS ! means bitwise instead of logical is not something we want to ask
• KN: When it comes to small/trivial things in the syntax we should err on the side of being like JS as that’s the native host language.
• DM: So, having all the conversions JS has?
• JG: No. Core point, if the main goal is fewer operators would entertain ~ on bools. Pretty against ! to mean bitwise negation.
• KN: The problem I have with ! for bitwise not is specifically it does something different in almost every other language. Agree with JG that if we want one using ~ would be the one
• RM: Agree
• GR: Don’t consider this implicit conversion. Binary ops take different types and convert to bool like == this is just a unary operator that does the same thing.
• MM: So was that an argument for 2 symbols or 1?
• GR: Argument that says we could have a ! operator as negation as some of the pushback was it’s implicit conversion which I don’t see
• DM: Just unnecessary as you can express without the overload. Number of cases you need is small
• GR: You say unnecessary because you can say == 0?
• DM: Yes
• JG: I have GLSL code that does that that I don’t case to bool as I don’t have too
• KN: Why not just write == 0?
• JG: Recommended against in most modern style guides.
• MM/DJ: Our style guide prescribed that
• MM: The reason we do ! instead of ==0 is it’s shorter. Disagree with the style guide here as the loss in clarity is not worth the extra 2 characters.
• JG: Where we can go from here is I think there is consensus that we want a bit complement operator and that there is consensus ~ is the best bitwise operator symbol to use and if we want to have one symbol for both bit complement and logical negation (to discuss later) we should prefer to use the operator which is least surprising which is ~ for everything. To move forward add ~ bitcomplement and then DM make proposal to replace ! with ~ would be the best way to move towards one symbol.
• DM: My feeling is compromising on ~ is what no-one wants. With ! there is prior art in Rust which uses it for both with ~ it isn’t used for both.
• KN: Many languages you can
• MM: In c++ it will do the right thing.
• JG: My perspective is familiarity with other languages and principle of least surprise that looking the code written by WGSL authors can you look at hte code and see what its doing. Someone seeing ~ for logical not would understand but would mis-read !.
• KN: Clang says bitwise evaluation of bool always evaluates to true.
• RM: I think a strong argument is less people reading vs writer. If the writers are more familiar with c or c++ vs rust. If using ! for both int and bool then they can use it on an int wanting to get logical not and get bitwise negation which is the kind of thing that can be very painful to track. Not something they would thing this operator i’ve been using is doing something different in this language
• DM: Would see in shader compilation error. That’s the main thing. Float a === b does nothing in c but gives error in WGSL if a and b types don’t match. Cant’ take one part of c and ignore others.
• RM: Can’t given compiler error for ! meaning different things for different types which means it’s valid for both types which means we don’t know it’s wrong
• DM: Yes, but there is conext it’s used in and the user knows the context needs a bool or integer, no likely both.
• RM: User doesn’t necessary know the entier WGSL spec they’re a c++ programmer that’s seen WGSL and wants to write/modify and writing some valid c/c++ code we should either return an error saying it’s wrong or do something they consider sensible. Not just say, fine that compiles and runs nad doesn’t crash and is fine but returns a differnet result then expected.
• GR: I think replacing c++ programmer with JS programmer it’s a more compelling argument. Is that true in what’s said?
  RM: I think so
• KN: JS always does implicit conversions. The type is a property of the op not the thing. So ~true in JS gives -2 as true convert to 1.
• DM: Can only think of one context where there isnt’ an immediate error from teh compiler, if the user mistakenly assumes the ! is something else. That is with the mix operator which may take float/int or bool. All other contextes there is no overload and the user will get an error 99% of the time and will correct themselves. There is no danger of incorrect results.
• RM: Understand better what you’re saying because the output type is the same as the input type. That’s a fair argument.
• MM: Another argument that in src code the ! operator is more common then ~ and so, not having ! developers will try to put in ! and get compile error and say this is silly and have to use this other character because the language is garbage. So, this is an argument for 2 operators, not for ! being overloaded.
• DM: Ok, don’t want to stall further, accept disagreement and go with 2 ops with a note we sort of have this for boolean ops which has different symbols for booland int. And we don’t want to use !! so we use ~.
• DJ: Unicode emoji (joke)? . Generally agree for ! for logical op.
• DC: Some keyboards don’t have ~.
• MM: That’s a good point.
• DC: Spanish, Italian, etc.
• MM: So they’d have to search for it?
• DC: Would have to map the unicode key thing …
• JG: Sounds like trigraphs
• DN: No, no you aren’t.
• MM: What is the final decision?
• JG: 2 ops for readability with a note with ‘these aren’t technically necessary but are there for readability’
• MM: And one is for bools and the other is non-bool scalars?
• DN: Integral scalars and integral vectors
• MM: Yes, that makes sense. Cool. You can’t use one when the other is correct.

• MM: Not much to discuss, one thing, we’re internally gathering data. Understand if you can’t speak publicly but would like to know GPU
• DN: Nvidia Quadro something?
• KN: Probably P4000
• GR: One of the minimalist ones or one of the expensive ones
• DN: Workstation from last year, probably expensive. Don’t have older nvidia that would have subgroup. My understanding is the compiler infra on nvidia is similar across GPUs. If you have subgroup would probably be similar. From turing onward Nvidia put strong emphasis on forward progress to handle real world ISO C++ on the GPU, including forward progress guarantees from more recent C++ standards. Expect the behaviour to get more extreme
• MM: Is the card using, is that one of the turing cards?
• DN: Don’t know. Can lookup but don’t remember.
• MM: Is it possible to get details specs in weeks/months? We’d appreciate that.
• DJ: Any more to discuss?
  MM: Not at this time.

• DN: I was playing …. IF we want LALR grammar then I wrote a perl script that would extract something that could go through bison which replicated some of the issues from MM on the ambiguity on LR. Then DS said want recursive descent LL(1) then I stopped working. It’s an exercise on how it's feasible to extract the grammar using heuristic. Still work in progress, just stalled.
• MM: Does the fact it stalled mean we should ignore it or is this a real thing?
• DN: Higher order bit is if it’s an LL or LALR grammar.
• DJ: Memory of issue is no-one expressed strong desire outside of DS. So we’d be happy with LL(1)
• KN: My understanding is recursive descent is between LL(1) and LALR(1)? LL(1) is considered too restrictive to be useful
• DS: Technically the grammar isn’t LL(1), it is close. It isn’t recursive descent, but is trivially convertible to that. I want it to remain that way.
• RM: In practise, it’s possible to produce something recursive descent like for any kind of reasonable grammar. Can pretty much always do something since most real parsers are some variation on recursive descent. Don’t think it’s too much of a restriction.
  DN: Would like to have a formal check we dont’ have ambiguity. Know from reputation that a lot of the time people writing parsers like recursive descent because they’re easier to understand, maintain and get contextual error messages. Clang, etc which use recursive descent. Want formal check for properties and ease of maintenance
• RM: Agree
• MM: +1
• DJ: Don’t necessarily care what it was, just want formality check. Whoever maintains tooling and checker can dictate/suggest what is the best.
• MM: Couple things worth discussing. 1- extract-idl.py script in webgpu is similar. That script is smaller/simpler. Hoping you could describe why script is so much bigger.
• DN: at ~ 60 lines of perl got most text extracted then exceptions cleaning up things like spirv equivalents which are freeform so it removes those. Ends up building JSON like representation of grammar and tokens and rules. Also have regex annotations like * and ? and () and it splits those into their own bits if they have whitespace or not. Then generates a correct a lex and bison grammar which by running i have something i can run through those tools on the command line. Bunch of cleanup heuristic. If cleaned up draft would remove a bunch of stuff
• JG: We should do that
• MM: I’d like to do that. Would like grammar extract to be similar to extract-idl.py
• DN: Yup, was an explortation which exposed
• MM: One is python, one is perl. I vote not perl but willing to be convinced.
• DN: Fine, as long as i don’t have to write python.
• MM: Sounds like we have a path forward.
• DN: Sounds like we can have a set of cleanup steps that removes/simplifies the weird cases in draft spec
• MM: One other topic, which is editorial, in bison there are no *’s and +’s so we could go either with *’s and +’s and use a tool that uses them or we turn *’s and +’s into helper rules and put those in the spec.
• DN: Next though was I like the regex stuff in the spec. Next step would would be to do that mechanical re-write in the translation out, introduces risk but makes the grammar understandable.
• MM: I think i’m there in philosophy, one tricky thing to understand, in the tool that takes * and + and adds helpers and how do i know where that script uses * and +.Do I have to use the script to expand that rule if I have complicated grammar?
• JG: Just syntactic sugar
• DN: If I understand what you’re saying, if I have a malformed rule in the original spec then I might be in a grey area and not sure what the tool produces.
• MM: Not concerned about malformed. When I manually turn * and + into helpers it involved thinking, not mechanical, looking at collection of rules and pushing together to make grammar bison accepted that wasn’t ambiguous. Little skeptical that could be done in general. Confident it could be done for how we use now. If the tool takes some formulations but not all formulations then I’ll write a new rule and will have to teach the tool how to use * and + as we are.
• DN: Wasn’t concerned about that, but if others doing that work go for what you need.
• MM: Propose putting helper rules in spec.
• DN: That removes all risk.

• DN: Not consensus at Google either. DS doesn’t like it JK doesn’t like not having a-5. Me workshopping, didn’t turn out bad but shifts translators out to other formalisims as if you need a negative constant on a negation you can emit it.
• DM: Don’t have constant propagation.Wouldn’t that require it for the user to write -5.0.
• DN: Requires you to recognize the pattern in the 1 case.
• DS: I’m not sure if the A-5 case is that common. I usually add spaces. I haven’t found it to be an issue. We introduce issues if we include this. e.g. what is a--5?
• JG: Maybe requiring a space isn’t too bad? Other languages have required a space at first, and then work out how to update the grammar to reduce the need for spaces.
• MM: Sounds reasonable.
• JG: Tricky thing mentioned but not resolved is INT32_MIN is not parsible. Parsing INT32_MIN requires special care after this. Before this it’s a negative integer and is valid. Now when parsed as 2 tokens INT32_MAX + 1 isnt’ a valid INT32 value.Can’t convert token into a valid int32 for use with - operator
• MM: Guess bounds checking has to be done in stage that merges minus. As long as spec is well spec’d it will be oK. From an authors point of view it will be OK.
• DN: Also nature that going this way then we can flip back. If we start of with - in token don’t think we can change back?
• DJ: Suggestion is requiring a space.
• JG: that would be not accepting this PR.
• MM: What has to happen for this PR to be accepted?
• DJ: Something we can decide later? Do we need this for MVP.
• MM: Parsing integers is pretty basic.
• JG: Yes but we can already parse integers. The core thing is the note in teh space that you need a-5 is A MINUS_FIVE and not A MINUS FIVE. You need a - 5 fo the second. To me that’s fine for MVP to say you have to take special care in this case else parsing error. Seems easier then figuring out how to remove the negative marker from literal tokens which seems harder. Including things like declarations of arrays of negative integers.
• DJ: Let’s leave and finish next meeting.