This can help with concerns raised in #643.
cc: @dneto0

This works for me.

The return and kill parts of this are probably overreach.

I don't think we have the evidence to suggest that a grammar complication is needed.
What is the scenario we are trying to avoid, exactly, by introducing this grammar?

if (c) break; is really really close to break if (c);, without adding an unusual new break form.

As for kill and return, I think it makes sense to include them as control-flow keyword branches. if (cond) return; is an early-out pattern I use a lot in systems programming, at least. (kill I'm less attached to, but it fit the pattern of the group) Individual project style can (as always) forbid them if desired.

This proposal splits the difference between being opinionated/strict and flexible/expressive.

Although I am not in favor of removing braces after an if as a general rule, I would be willing to accept a PR that allows it for the case where there is just a break/continue/return/kill statement in the branch.

But this is not at all what this pull request does. I see several issues with its changes to the grammar:

• It keeps the construct "break if (foo)". So now something like "if (foo) break if (bar);" would be legal, and that looks unreadable to me.
• It removes break/continue/return/kill from the list of normal statements, so that they can only be used inside a branch, and as the only thing inside that branch. I don't want to have to write "if (true) return x;" whenever I want to return x !
• It refers to a keyword_stmt class which does not appear to be defined anywhere.
• Because it modifies body_stmt it also allows a bare keyword as the only body of a function, which seems syntactically weird to me.

For each of those I'd like to know whether it is intended or just an accident.
Replacing keyword_stmt by branch_stmt would fix 2 and 3, so I think that was the original intent.

This was discussed at the 2020-05-12 meeting.

There is a loophole in this approach:

bool my_crazy_function() {
 // do crazy uniform-restricted things
}
...
if (break_condition) return my_crazy_function();

Unless we have special rules for the return expressions in the uniform control flow analysis, the expression has to adhere to the same restrictions as anything else in a if (break_condition) { block of code } block.

I could see 3 solutions to this:

• restrict if (...) return to a limited form, without general expressions
• modify the uniform control flow analysis (unless it already treats return conditions specifically?)
• always require braces for if {}

I expressed concern regarding this change for the dangling-else problem. I wanted to look into it further to convince myself it was or was not an issue. As I read the grammar, I see that this change introduces no way to follow an if (cond) with another if(cond2) without including a bracket which would prevent any ambiguity.

I think @dj2 makes a good point that this would introduce a rather strange function definition. As such, I'd support the introduction of if_body_stmt as a fairly minor alteration to this change. I confess that either way, as it stands, I don't think the concern I raised should be the driving force to prevent this limited alteration.

Apologies if I came on too strong earlier. Nevertheless, I feel this additional consideration has been beneficial.

Discussed at the 2020-06-02 meeting.

Discussed at the 2020-09-29 meeting.

With required braces, the dangling else problem is naturally solved. We should not make a change which creates the dangling else problem.

Also, consider something like

if (foo)
    /* take an early out! */
    break;

This code is unclear.

I believe this PR does not have a dangling-else problem, as you cannot write if (foo) if (bar) else. According to Wikipedia's Dangling Else article, this sort of functionally similar to how ALGOL 60 avoids this issue.

Possible solutions are:

• [...]
• Disallowing the statement following a "then" to be an "if" itself (it may however be a pair of statement brackets containing only an if-then-clause). This approach is followed by ALGOL 60.

Allowed:

if (foo) {
  if (bar) return -1;
  else return 1;
}

if (foo) {
  if (bar) return -1;
  else {
    return i + 1;
  }
}
if (foo) {
  if (bar) {
    return -1;
  } else return i + 1;
}

if (foo)
  // early out
  return -1;

Discussed at the 2020-12-08 meeting.

Resolution: Land this as is unless people speak up by next week.

We discussed this for a long time, and I think the discussion has evolved a bit.
On the last call this was positioned as a convenience feature (quality of life).
My concern with this is still - that it's not necessary, it can be added after MVP, and it's highly controversial in existing languages like C++.

Edit: the de-factor standard C++ code formatter - Clang-tidy - has a rule "readability-braces-around-statements" specifically to handle that, and it's enabled by default. Mozilla's ./mach static-analysis also warns about it.

It seems like WGSL syntax is heavily inspired by Rust, which has managed to get by just fine without such syntax. Adding this has the downside of precluding other possible syntax extensions, and it also introduces unnecessary special-cases into the grammar (in order to avoid the dangling-else problem).

You need only look at Javascript to see the problems with adding too much syntax too quickly. It is much better to start with a simpler grammar, and extend it later with sugar and "nice to haves" once you have a body of real code against which you can evaluate the benefit of any potential additions.

Thinking about this some more, I think it falls into the bucket of "we can't undo this later, but we can add it later". The change itself is simple enough, but it isn't strictly adding anything that can't be done without it and being in the can't undo bucket, I think we should punt this to post MVP.

We discussed this for a long time, and I think the discussion has evolved a bit.
On the last call this was positioned as a convenience feature (quality of life).
My concern with this is still - that it's not necessary, it can be added after MVP, and it's highly controversial in existing languages like C++.

Edit: the de-factor standard C++ code formatter - Clang-tidy - has a rule "readability-braces-around-statements" specifically to handle that, and it's enabled by default. Mozilla's ./mach static-analysis also warns about it.

FWIW, unsurprisingly I have fought to get this warning disabled for certain directories in Gecko, where the prevailing style embraces succinct braceless early-outs. I feel relatively strongly about this requirement being overly restrictive and generally supported merely via personal opinions and strawman arguments like goto-fail.

I know we all have opinions here, but this isn't a choice between how your code will be written, but rather whether one camp's code style is allowed to be written at all. The most equitable thing is to support both camps, absent anything particularly onerous.

I don't think we will have more data here unless we allow this for MVP and check if people use it. This is a minor enough papercut that people (me) will grumble when writing it, but it won't end up on any powerpoint slides about pain-points. However, it seems easy enough to spec and support, and @dneto0 and I are already extant users requesting it for two different reasons.

I propose we take this now, and if we run into any onerous aspects here, we can remove it before v1.

this isn't a choice between how your code will be written, but rather whether one camp's code style is allowed to be written at all.

It's not really a style question if it doesn't exist in the language to begin with. Perhaps it should be possible to omit brackets entirely and use indentation to delimit blocks: that's required in python after all.

The problem with this argument is that WGSL is not python, or C++, or any other language.

I propose we take this now, and if we run into any onerous aspects here, we can remove it before v1.

Adding every possible feature and then removing them later is a bad way to design a language and invites code breakage for no benefit.

We are at the stage of language development where we are deciding what styles are and aren't allowed, and this is exactly that sort of style question.

I agree that we should not add literally everything, but I've made my case that this makes the cut.

Specifically, at this point there has been consensus that this is tolerable, spec-able, and implementable, so I'm looking for any arguments that it's onerous or unduly risky such that we should not proceed with the consensus that we have already reached, even if it was a weak consensus.

We are at the stage of language development where we are deciding what styles are and aren't allowed, and this is exactly that sort of style question.

From what I've seen, most of the spec is fairly minimalist and driven from an actual need. For example, clearly you need some way in the language to manage control flow, therefore you need if, while, etc. You don't need two ways to write an if statement.

I agree that we should not add literally everything, but I've made my case that this makes the cut.

All you said is that you feel strongly about it, and that it's possible to implement. I don't doubt either of those things, but the same argument applies to almost everything.

Significant whitespace is clearly possible to implement since python has it, and I guarantee there exist people who feel strongly about that (having encountered several wanting to add this feature to Rust and C++).

The barrier to entry for new features, especially early on like this should be far higher than a personal preference.

Given that we don't need this now, there's rough consensus that we probably want to hold off on it for now, but that we can add it later. Maybe people will express positive interest in it, or maybe we'll just feel like adding it, but we're inundated with work right now and this is probably low priority.

Fwiw @Diggsey I don't think this has the same bar as other sophisticated "new features", as it's ultimately a minor quality-of-life improvement, while also being fairly trivial to implement.
With my API design hat on, this is something that I think is valuable, I just also happen to be a vocal user who's asking for it.

@kdashg I think this PR could be closed since WGSL now supports paren-less control flow, which means conflicts with bracket-less control flow. (though we could allow control flow to be either of bracket-less or paren-less, but ew?)