-2

Why is for(;;) treated as an infinite loop while while() gives an error as it requires an expression? Why don't for loops expect expressions, too?

Blaze
  • 16,736
  • 2
  • 25
  • 44
A81
  • 181
  • 2
  • 12
  • No need to re-tag. A good C++ answer will go into just as much depth as a C answer. – John Kugelman Jan 04 '19 at 13:50
  • 1
    Via Max, these are probably dupes tbf https://stackoverflow.com/questions/13146830/no-loop-condition-in-for-and-while-loop https://stackoverflow.com/questions/13366290/why-can-the-condition-of-a-for-loop-be-left-empty (particularly that last one) – Lightness Races in Orbit Jan 04 '19 at 13:55
  • 2
    Plus, it might be confusing. To me, `while ()` looks like `while (false)` or `while (NULL)`, not `while (true)`. – 001 Jan 04 '19 at 13:58

3 Answers3

10

It just… doesn't.

while could have been made to permit an empty condition (which would presumably be interpreted as true), but then it would be asymmetrical with if for which this would make less sense.

Ultimately, there is no compelling reason to permit an empty condition in while preamble as any code using this would not be self-documenting.

For symmetry with for, you could require for(; true; ) — except now this looks weird because the declaration and update clauses may now be empty whereas the condition can't. Okay, let's make those mandatory too. So, what do we put in those places for no-ops? for (int dummy = 0; true; (void)dummy)? Now it's getting silly.

They're different language features and there's no strong reason to make them work the same way in this regard at the expense of other considerations.

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
  • Nice expl. note: _"To be more precise why for loop doesn't expect an expression[?]"_ --> http://eel.is/c++draft/stmt.for#2 I guess – YSC Jan 04 '19 at 13:55
1

Disclaimer: this answer explains why the syntax is valid, not why it was designed that way.

According to the documentation (emphasis mine):

formal syntax:

attr(optional) for ( init-statement condition(optional) ; iteration_expression(optional) ) statement

So all that is required is the init-statement and a ;. And for the init-statement, it says:

an expression statement (which may be a null statement ";")

So as a result, if you leave away the optional things and put a ; for the init statement, all you get is ;;.

In C it's a bit different:

for ( init_clause ; cond_expression ; iteration_expression ) loop_statement

init_clause, cond_expression, and iteration_expression are all optional

That's the two ; and three optional clauses/expressions. If you omit all three, you get ;; again.

Blaze
  • 16,736
  • 2
  • 25
  • 44
  • 4
    I think the question is _why_ (though I'm not saying that my attempt to answer that question is amazing) – Lightness Races in Orbit Jan 04 '19 at 13:52
  • You're right. There's some ambiguity here. It could be interpreted as "why is it like this" or as "why did the rules define it like this". – Blaze Jan 04 '19 at 13:54
  • See, I'd interpret both those statements the same :P As the OP has already discovered that the language permits one and not the other and restating this observation in standardese doesn't really add to our understanding :) – Lightness Races in Orbit Jan 04 '19 at 13:56
  • True that. The way I interpreted it, I thought OP wanted to know if there's some syntactical trickery going on that allows the statement in `for` to be omitted, but doesn't work in `while`. Anyway, I appreciate your answer to OP's question, I never thought about this much but now I know. :) – Blaze Jan 04 '19 at 14:03
0

This is a language design question, so language designers should chime in. My opinion: the optional features (specially shortcuts) of a language should PREVENT MISTAKES. So, while() is easily a mistake (you omitted the conditional, eg. 0 or 1), whereas for(;;) is rarely a mistake (you have to consciously type the 2 ;).

Gambit Support
  • 1,432
  • 1
  • 7
  • 17
  • Mm yeah that's a good reason not to worry about the asymmetry – Lightness Races in Orbit Jan 04 '19 at 13:58
  • 1
    And answers such as this are precisely why the question is primarily opinion based, and should be closed as such. This answer expresses a valid opinion and a plausible explanation, but it is still just an opinion. – John Bollinger Jan 04 '19 at 13:59
  • 1
    @JohnBollinger I _think_ we've tended to permit "why was X designed this way" because the reasons are often objectively determinable from contemporary sources or reports from language designers who have practical reasons we may not have considered. The choice itself may have been subjective but we can usually report those rationales objectively. (This is in contrast to code style type questions which are subjective at the point of sale, and that's what the rule is designed to eliminate.) Though in this case I'm not sure the rationale, if any ever truly existed, is discoverable. – Lightness Races in Orbit Jan 04 '19 at 14:00
  • 1
    @Lightness, I would be fine with an answer that provides Kernighan and Ritchie's actual rationale for this design choice, or even an analysis of language design of the time that produces a third-party conclusion about such a rationale. But this particular question seems unlikely to yield such an answer, and we are left in exactly the situation that the "primarily opinion-based" close reason is meant to head off. – John Bollinger Jan 04 '19 at 14:17
  • 1
    @JohnBollinger Well, you don't know until you ask ;) I have seen plenty of questions like this where such an answer is available. "We don't know" is a valid answer otherwise. I still think that leaves the question itself on-topic as it is not, in and of itself, soliciting advise or opinions on subjective matters. – Lightness Races in Orbit Jan 04 '19 at 14:18