[marcoms]

What's the argument for required brackets around if (conditions) and switch (conditions)? To me they seem redundant.

--

As a side point, I hope switch statements are less like C and more like Rust (Rust happens to have better looking syntax, not just because its Rust):

    match <identifier> {
        <val> => {
            //
        }
    
        ..
    }

C-style always creates confusion on how to indent blocks following case statements

[david-given]

Having tried this in the past with personal programming languages, I always found I needed the parentheses to disambiguate control flow statements. You end up with stuff like:

  if foo*bar baz()

...being parseable as either of these:

  if (foo) { *bar } baz()
  if (foo*bar) { baz() }

That example can be solved with enough lookahead but I think I found cases where it couldn't be (although I can't bring them to mind). Terminator tokens are another way to solve it, so you get Ada-style:

  if foo*bar then baz() endif

...or Go-style:

  if foo*bar { baz() }

[erikpukinskis]

If you stop putting multiple expressions per line it disambiguates too:

    if foo
      *bar
    baz()

    if foo*bar
      baz()

[klibertp]

That's only if newlines are meaningful in the grammar. In C and related languages they are not, and where they are they tend to be a pain (the dreaded semicolon insertion...)

And even if you make newlines meaningful you only trade one pain for another, namely, you now need some kind of line continuation construct and lots of special cases where newlines are allowed...

In short: it's not that simple.

[erikpukinskis]

Can't you just treat newlines like any other delimiter? Granted many tools assume newlines, but you could just not use those tools, or replace newlines with a placeholder so you can parse programs as a single line.

[__s]

Rust confronts this by making curlies mandatory

[macintux]

What you really should be asking for is replacing switch clauses with function heads like ML or Erlang. </soapbox>

[yarrel]

The argument (which I agree with, although it can be a pain to adopt at first):

http://wiki.c2.com/?AlwaysUseBracesOnIfThen

[tekacs]

What you linked is about braces around the /body/ of an if statement.

What the GP poster was talking about was parentheses around the /conditions/ of an if statement.

Note that Rust (for example) doesn't require the latter.

In fact, if you always require braces (as in the post that you linked), then it's very easy to parse and read code which is lacking those parentheses on the condition.

i.e. `if (condition) x = x + 1` would be hard to read without parens. but `if condition { x = x + 1 }` (with mandatory braces) is quite clear.

[weberc2]

The GP said brackets, not parens. Perhaps he misspoke?

[david-given]

Ah, yeah. I didn't twig until you mentioned it, but... if ever you get tired of emacs vs vi religious wars, try switching to discussing whether 'bracket' refers to a parenthesis or a brace.

Given the context, I'm pretty sure the OP was using the 'parenthesis' meaning.

[zem]

in commonwealth english, it's most commonly "brackets" for (), "square brackets" for [] and "curly brackets" for {}

[david-given]

Yeah, that's what I grew up with.

Where is it otherwise? Is bracket={} a USism? I've never been sufficiently aware to isolate the demographic.

[whiteandnerdy]

In British English, 'brackets' means parentheses, as opposed to square brackets or curly brackets (also called braces). Maybe OP uses British English.

[tekacs]

I'm also British, which may explain why I was able to read the GP's post first time.

[weberc2]

Ah, I never knew. Thanks for the information.

[marcoms]

As others speculated I meant parentheses around the condition - my mistake, I should have qualified

[achamayou]

Just the lack of fall through by default is already a significant improvement.