Why do languages require parenthesis around expressions when used with "if" and "while"?

Question

Languages like C, Java, and C++ all require parenthesis around an entire expression when used in an if, while, or switch.

if (true) {
    // Do something
}

as opposed to

if true {
    // Do something
}

This seems odd to me because the parenthesis are redundant. In this example, true is a single expression on its own. The parenthesis do not transform its meaning in any way I know of. Why does this odd syntax exist and why is it so common? Is there a benefit to it I'm not aware of?

Answer 1

There needs to be some way of telling where the condition ends and the branch begins. There are many different ways of doing that.

In some languages, there are no conditionals at all, e.g. in Smalltalk, Self, Newspeak, Io, Ioke, Seph, and Fancy. Conditional branching is simply implemented as a normal method like any other method. The method is implemented on booleans objects and gets called on a boolean. That way, the condition is simply the receiver of the method, and the two branches are two arguments, e.g. in Smalltalk:

aBooleanExpression ifTrue: [23] ifFalse: [42].

In case, you are more familiar with Java, this is equivalent to the following:

aBooleanExpression.ifThenElse(() -> 23, () -> 42);

In the Lisp family of languages, the situation is similar: conditionals are just normal functions (actually, macros) and the first argument is the condition, the second and third argument are the branches, so they are just normal function arguments, and there is nothing special needed to delimit them:

(if aBooleanExpression 23 42)

Some languages use keywords as delimiters, e.g. Algol, Ada, BASIC, Pascal, Modula-2, Oberon, Oberon-2, Active Oberon, Component Pascal, Zonnon, Modula-3:

IF aBooleanExpression THEN RETURN 23 ELSE RETURN 42;

In Ruby, you can use either a keyword or an expression separator (semicolon or newline):

if a_boolean_expression then 23 else 42 end

if a_boolean_expression; 23 else 42 end

# non-idiomatic, the minimum amount of whitespace required syntactically
if a_boolean_expression
23 else 42 end

# idiomatic, although only the first newline is required syntactically
if a_boolean_expression
  23
else
  42
end

Go requires the branches to be blocks and doesn't allow expressions or statements, which makes the curly braces mandatory. Therefore, parentheses aren't required, although you can add them if you want; Perl6 and Rust are similar in this regard:

if aBooleanExpression { return 23 } else { return 42 }

Some languages use other non-alphanumeric characters to delimit the condition, e.g. Python:

if aBooleanExpression: return 23
else: return 42

The bottom line is: you need some way of telling where the condition ends and the branch begins. There are many ways of doing so, parentheses are just one of them.

Answer 2

The parenthesis are only unnecessary if you use braces.

if true ++ x;

For example becomes ambiguous without them.

Answer 3

Parentheses in an if statement do not have the same meaning as parentheses used within an arithmetic expression. Parentheses in an arithmetic expression are used to group expressions together. Parentheses in an if statement are used to delimit the boolean expression; that is, to differentiate the boolean expression from the rest of the if statement.

In an if statement, parentheses do not perform a grouping function (though, within the if statement, you can still use parentheses to group arithmetic expressions. The outer set of parentheses then serves to delimit the entire boolean expression). Making them required simplifies the compiler, since the compiler can rely on those parentheses always being there.

Answer 4

As other have already partially pointed out this is due to the fact that expressions are also valid statements, and in the case of a block with just one statement you can drop braces. This means that the following is ambiguous:

if true
    +x;

Because it could be interpreted as:

if (true + x) {}

instead of:

if (true) {+x;}

A number of languages (e.g. Python) allow you to avoid the parenthesis but still have an end-condition marker:

if True: +x

However you are right that we could define a language where the parenthesis are never required: a language where an expression is not a valid statement will not have this problem.

Unfortunately this means that things like:

 ++x;
 functionCall(1,2,3);

would not be valid statements, so you'd have to introduce some weird syntax to be able to perform such actions without creating expressions. A simple way to do this is to simply prepend the expression by a marker like [statement]:

[statement] ++x;
[statement] functionCall(1,2,3);

Now the ambiguity disappears since you'd have to write:

if true
    [statement] ++x;

But as you can see I don't see such a language be widespread since putting the parenthesis around an if-condition (or a : at its end) is much better then putting such a marker for every expression statement.

---

Note: the use of a [statement] marker is just the simplest syntax I could think of. However you could have two completely distinct syntaxes for expressions and statements with no ambiguity between them which would not require such a marker. The problem is: the language would be extremely weird since to do the same things in an expression or a statement you'd have to use a completely different syntax.

One thing that comes to mind to have two separate syntaxes without such an explicit marker would be, for example: force statements to use unicode symbols (so instead of for you'd use some unicode variation of the letters f, o and r), while expressions to be ASCII only.

Answer 5

It is common for C-family languages to require these parentheses, but not universal.

One of Perl 6's more noticeable syntactic changes is that they modified the grammar so that you don't have to give the parentheses around if, for and similar statements' conditions. So something like this is perfectly valid in Perl 6:

if $x == 4 {
    ...
}

as is

while $queue.pop {
    ...
}

However, because they're just expressions you can put parentheses around them if you want, in which case they are just ordinary grouping ones instead of a required part of the syntax as they are in C, C#, Java etc.

Rust has similar syntax to Perl 6 in this department:

if x == 4 {
    ...
}

It seems to me like a feature of more modern C-inspired languages is to look at things like this and wonder about removing them.

Answer 6

There is one aspect which I am surprised that none of the existing answers have brought up.

C, and many C derivatives and look-alikes, has a peculiarity in that the value of an assignment is the assigned value. A consequence of this is that an assignment can be used where a value is expected.

This allows you to write things like

if (x = getValue() == 42) { ... }

or

if (x == y = 47) { ... }

or

unsigned int n = 0 /* given m == SOME_VALUE */;
while (n < m && *p1++ = *p2++) { n++; }

(which is implicitly treated as while (n < m && *p1++ = *p2++ != 0) { n++; } because C treats non-zero as true; incidentally, I think that's just about strncpy() in the C standard library)

or even

if (x = 17);

and it is all valid. Not all syntactically valid combinations are necessarily useful (and modern compilers specifically warn about assignments inside conditionals, because it is a common error), but some of it actually is useful.

Parsing such statements would likely be far more difficult if there was not some unambiguous way to determine where the conditional expression begins and ends.

Parenthesis were already used to delimit function names from function arguments, so I guess they seemed like a natural choice also to delimit keywords from keyword arguments.

Sure, alternative syntaxes could be defined to do the same thing. But doing so would increase complexity, particularly in the parser which would then need to deal with two different sets of syntax for largely the same thing. Back when C was being designed, computing power (both in terms of number-crunching ability, working memory, and storage capacity) were extremely limited; anything that reduced complexity at little or no cost to readability was almost certainly a welcome change.

Using parenthesis might seem slightly archaic today, but it's not like that given someone with some familiarity with the language, it impairs readability compared to some other syntax that is capable of expressing the same things.

Answer 7

The reason is mostly history.

At the time that the first C compiler was written, computers have very limited ram, cpu and compilers where written “by hand” with few tools to help compiler writers. Therefore complex rules were costly to implement in a compiler. C++, C#, Java, etc were all designed to be easy for C programmers to learn, hence there was no “unnecessary” changes made.

In ‘c like' languages conditionals (if, while, etc) do not require an explicit block off code, you can just use a simple statement.

if (a == d) doIt()

or you can combine statements together into a compound statement by putting them with in {}

We like the compiler to find error we make and to give as an error message we can understand.

Answer 8

Java and C++ both were developed after C had become a very popular programming language. One consideration in the design of each of those languages was that it would appeal to C programmers and woo those programmers to use the new language. (I was one of the C programmers they wooed successfully.) C++ additionally was designed to be (almost) interchangeable with C code. In order to support these goals, both C++ and Java adopted much of C's syntax, including the parentheses around the conditions of if, while, and switch statements.

Hence the reason why all these languages require parentheses around the conditions of those statements is because C does, and the question is really just why C requires those parentheses.

The origins of the C language are described in this article by Dennis Ritchie, one of the principal authors of its development (some might even say the principal author of its development). As told in that article, C was originally developed in the early 1970s as a system programming language for computers with extremely limited space in main memory. It was desired to have a language that was higher-level than assembly language, but given the resources available to work with, the ease of parsing the language was also important. Requiring the parentheses would make it relatively easy to identify the conditional code.

One might also infer that the ability to write programs using fewer characters was considered an advantage, and two parentheses take less space than the keyword THEN that was used in FORTRAN and other high-level languages at that time; in fact, since the parentheses could also replace spaces as delimiters of symbols, if(a==b) was four whole characters shorter than IF a==b THEN.

In any event, some balance had to be struck between how easily human beings would be able to read, write, and understand programs written in C, how easily a compiler could parse and compile programs written in C, and how many kilobytes (!) would be required both for the program source and the compiler itself. And parentheses around the conditions of if, while, and switch statements was how people chose to strike that balance in the design of C.

As evidenced in several other answers, once you take away the particular circumstances under which C was developed, all kinds of alternative forms of syntax have been used for the conditionals of various programming languages. So the parentheses really just come down to a design decision that was made by a few people under certain constraints at a certain time in history.

Answer 9

Many here reason that without the parentheses the syntax would be ambiguous and imply silently that this would be somehow bad or even an impossible situation.

In fact, languages have lots of ways to deal with ambiguities. Operator precedence is just one instance of this topic.

No, ambiguity isn't the reason for the parentheses. I guess one could simply create a version of C which does not require the parentheses around the condition (thus making them optional) and which still creates valid code in all cases. The example of if a ++ b; could be interpreted as being equivalent to if (a) ++b; or if (a++) b;, whatever seems more appropriate.

The question of why Dennis Ritchie chose to make the () mandatory (and thus coining this meme for lots of derived languages) is rather a linguistic one. I guess the notion of stating clearly that the condition is an expression rather than a command was the father of the thought.

And in fact, C was designed to be a parseable using a one-pass parser. Using a syntax with mandatory parentheses around the condition supports this aspect.

Answer 10

Parentheses around if conditions are not required in Fortran, Cobol, PL/1, Algol, Algo-68, Pascal, Modula, XPL, PL/M, MPL, ... or any other language that has a then keyword. then serves to delimit the condition from the following statement.

The closing parenthesis in C etc. functions as then, and the opening one is formally redundant.

Above remarks apply to traditionally-parsed languages.