an idea about loop

[pache-Ak]

trafficstars

In C++ and others, we often code these:

while (true) {
  //  do something
  if (/* */ ) break;
  // do something
}

Like this, the condition is not always at the beginning or end of the loop body.

So why not try this syntax:

do {
  // do something
while (/* */）
 // do something
}

Traditional loops always put the condition at the head or tail, but we can make it appear where it needs to appear, even more than once, just like if break

Maybe we can use other keywords to act as continue.

For example again

do {
  // do something
  again(/* */)  // if (/* */ ) continue;
  // do something
  while(/* */)
  // do something
}

Or we do not provide conditions on the loop syntax, so that the programmer ends the loop with an if statement in the loop body：

while {
// do something
if (/* */) break
}

[Mootbing]

+1

[pache-Ak]

Maybe loop until` are better keyword :

loop {
until(/* */) 
again(/* */)
}

This way, we can use fewer keywords, more concise expressions, and clearer semantics.

Of course break and continue are also good, but sometimes there are hidden dangers:

loop {
if (...) {
 break;
}  

// if (...)
// break;
// this is not safe
}

To be on the safe side, the if statement should be forced to be followed by a compound statement. This is a bit long when dealing with break and continue, but it's still good writing.

My core idea is not break and continue, but the loop condition, we should not make the loop head or tail must be conditional, this is sometimes redundant, we just need to provide keywords such as loop to indicate this block is loop, letting the programmer handle loop termination as needed.

[OlaFosheimGrostad]

The C-idiom is for(;;){ … }, but I guess for { … } is a possibility… I've seen some that use the macro 'forever' so you get forever {…} :-)

[pache-Ak]

The C-idiom is for(;;){ … }, but I guess for { … } is a possibility… I've seen some that use the macro 'forever' so you get forever {…} :-)

I'm afraid of macros, it's not context friendly, it makes what I see inconsistent with what it actually is. Not using macros is a good thing.

And carbon's for range-for we can't use idiom for ( ; ; ) { ... } . I wish we can have a freer, more flexible, more concise, more elegant syntax.

[OlaFosheimGrostad]

Not using macros is a good thing.

Yes, indeed. Macros also make it very difficult to change the syntax later, so they better not add macros.

I wish we can have a freer, more flexible, more concise, more elegant syntax.

Yes, I think the designers have set themselves up for a lot of complaining by having so much redundancy in the syntax…

…but, as long as they don't add macro-like features then it should be possible to create an alternative syntax that compiles to the same abstract syntax tree.

[pache-Ak]

I have spend time to consider this problem again.

It's a good thing to remove the restricted position about the condition. But others may be a little ill-considered.

My thoughts about again until also bring limitations and redundancy.

for(;;) {
  if (/* */) {
    // do something
    continue;
  } // Mu thought about `again` is not well in this case
}

The traditional syntax combines conditionals with jumps, which is convenient but not suitable for all cases. But if we separate the two, we may have to write longer code.

loop {
  //  ...
  if (/* */) {
     break;
  } // This syntax uses three lines only to finish loop
  // ... 
}

I don't think most people want to do this, even if it gives us the most flexibility.

So should we separate conditionals and jumps to handle some special cases, even when typing longer code?

Thanks for taking the time to look at my half-baked ideas, good luck Carbon.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please comment or remove the inactive label. The long term label can also be added for issues which are expected to take time. This issue is labeled inactive because the last activity was over 90 days ago.