Unifying and modularizing the while / do feature set in c

Question

disclaimer: I'm a university student who's one-year-new to programming. Please don't slaughter me in your responses as I am still a human being

I have an idea that I want some feedback on. I am currently learning C and we just covered while and do loops. The following is some pseudo-code and an interpretation from the perspective of a compiler in a theoretical sense:

the compiler reads the following lines:

while(conditions){
    body
}

and sees that it is a simple while statement and executes it as such. Then, the compiler reads the following lines:

do{
    body
}while(conditions);

and sees that it is a simple do / while statement since it terminates with a semicolon and executes it as such. Then the compiler reads the following lines:

do{
    body1
}while(conditions){
    body2
}

and this is the definition of my idea, a do + while statement. The compiler knows this is a do + while statement since instead of terminating with a semicolon, the while statement opens a new body using a curly brace and then closes with a curly brace at the end of body2.

In my mind this unifies do and while into a modular feature set where you can either use while, do, or do + while. Functionally, the program would execute body1 at least once because it is not bounded by a condition set, then it would check the conditions of the while loop. If the conditions are not satisfied, the do + while loop would terminate. If the conditions are satisfied, the program would execute body2. After body2 is executed, the program would return to the top of the loop, which is body1, and execute it again (since it is unconditional), and then proceed down to the while conditions, looping over and over until the conditions are not satisfied. From what I can gather, it essentially adds nothing new in terms of base architecture. It simply takes a pre-conditional body1 from do and couples it to a post-conditional body2 from while and loops them together.

This (what I believe to be elegant) solution potentially bridges the gap between having separate functions dedicated to evaluating while conditionals so that you're not clogging up the conditions portion of the while loop with long lines of code, but also can clean up code that is on the cusp of needing its own condition function. Like for example you've got one condition that needs an if statement or something else that requires just a few lines of code. Rather than create an entirely new function when the other conditionals are so simple, you can execute a few lines of pre-conditional code every loop to check the validity of one condition before passing it to while(conditions) and have it be clean and readable.

Is there already an elegant solution to this problem? Would any of you actually use an implementation that looks like this? I look forward to hearing feedback on this idea. Even if it is negative I feel like it was a good thought experiment and I hope some of you feel the same way at least.

Answer 1

There are four obvious grounds for assessing a language feature: aesthetics, implementation cost, benefit, and interaction with other language features. I'll skip aesthetics because it's subjective, and implementation cost because I'm not really qualified. Maybe someone can find a link to the Eric Lippert blog that was mentioned in comments.

Interaction with other language features: block scope.

The conditional while section should start a new block, because automatic locals shouldn't begin their lifetimes unless the while condition succeeds at least once. It should also have access to anything that was visible in the while condition itself, otherwise it's behaving differently to a normal while loop.

However the while condition for a do-while has access to the do block scope, so for consistency this should too.

Now the second (conditional) block needs to be nested in the first (unconditional) one, but this isn't how it would be written.

That is, for consistency it would have to behave like:

do {
    body1;
    if(!conditions) {
        break;
    } else {
        body2;
    }
} while(true)

from a scope perspective (because body2 should be able to see everything mentioned in conditions, which should itself be able to see everything in body1).

I can't think of anywhere else two block scopes are implicitly nested without being written that way.

---

Benefits: unconvinced

It isn't clear to me that this is an improvement over existing do/while loops. Of course, perhaps I'd need to spend some time rewriting existing code to use these loops before understanding their elegance: I'm only saying that it's not immediately obvious.

We already have three loop forms, and since this isn't an entirely straightforward combination of the existing do/while, we would have to consider this a fourth. Perhaps we can express both do{}while and while{} loops as different partially-degenerate forms of do{}while{}, although I'm not completely sure this successfully keeps the complexity under control.

For comparison, take the extension from try/catch to try/catch/finally in languages without RAII. I can see what specific need it serves, and it doesn't alter scope behaviour or object lifetime much beyond being "like another catch block".

Answer 2

A do...while is only different from a while... in one respect - in a do...while the body is executed at least once, whereas in a while...do it may not be executed at all.

Your do + while statement can easily be achieved within the existing C syntax as follows:

do
{
    body1;
    if ( !conditions ) break;
    body2;
} while true;

The C language is already complicated enough, without adding more complexity!

Answer 3

This is a reasonable construct.

My preference with looping is either:

• when we know the count, counted loop, e.g. on count of N:

for (int i = 0; i < N; i++ ) ...

-or-

• when we don't know the count, then "infinite loop":

    for (;;) { // or while (1) {
        // unconditional stuff that occurs (before) each iteration
        if ( condition ) break; // termination condition
        // conditional stuff for an iteration
    }

As an instructor, I find that many students find while and do while difficult for writing new code, and as such, my conclusion is that these constructs are optimizations for reading code, but not great for initially writing code.  So, I encourage using either of the above two forms, as they lend themselves more to writing loops.  Should either the unconditional stuff or the conditional stuff be "nothing" then we can convert loops of the latter form into while or do while forms, respectively, if we so desire (and sometimes I don't).

My students find these forms easier to work when writing code, since it allows them to put down in source more what they're thinking than the other forms.

Let's also note the in the "when we don't know the count" form, we can provide more than one exit condition, mixed into the loop body.