while(cond)
{
...
if (cond2)
DoOnBreak();
break;
... // this never runs
if (cond3)
DoOnBreak();
break;
...
}
If you didn't get it correct in this case, what are the chances of making
an error in a more complicated case

Harsh. I was writing at 2am or thereabouts. Also you missed a semi-colon in

Personally I try to keep the body of a loop and in particular the control flow
simple. I try to avoid breaks and put anything too large separate functions
where possible.

Have you ever written real code at 2AM?

Frequently.

I'd like to have a language that
helps me not make mistakes. We're all human.

But you prove my point. At 2am reading code with multiple complex paths of
control flow is painful.

The other part is that it is very easy to forget to add the DoOnBreak to
one of the breaks (you try finding them all in old code) or adding it to
every new one (Now what needs to be done on break this time).
Also, it will work with mixin(string) when you can't get to the string.

That might be a more valid use. Care to post an example? I think we have to be
careful with mixin's. They could easily be as abused as macros. There's no
reason you couldn't write with a style that has an exit condition specified in
the mixin. I don't like the idea of having a mixin with a break or return
hidden in it (that goes beyond the scope of the mixin itself). That could make
it very hard to follow the control flow.

agreed, mixin can make for some nasty code.

I'd still like to see a real worldish example where new syntax helps
significantly.

I'm more worried about the programmer having to maintain code using bizarre
constructs. The compiler can be clever out of sight.

It's not about the compiler being clever, it about the code having fewer
internal dependencies.
I like the scope solution because it states stuff where it makes a
difference, not where it needs to be done. Also it states stuff in a way
that make the intention of the code more clear. "do this then" rather
than "when that, do this" or even worse "do this now" in several places.
I'll concede it is a style issue.

I like the idea of "do this then" versus "do this now". Its breaks out of in
the procedural (and even message passing OO style) where pretty much everything
is now but I'm not entirely convinced this is the best way to express it. The
body of a loop should have stuff to do with its body only. A finally block is
in the right place, at the end for example (that's not to imply I like the
earlier suggestion of adding finally blocks to loops either).
Regards,
Bruce.

Right I have found after some digging Andrei Alexandrescu's
original suggestion.
"I believe three constructs would simplify writing robust code:
1. on_scope_exit { ... code .. }
Executes code upon the current scope's exit. Several on_scope_exit
blocks in a scope are executed LIFO.
2. on_scope_success { ... code ... }
Executes code if the current scope is exited normally (no exception
engendered).
3. on_scope_failure { ... code ... }
Executes code if the current scope is exited via an exception.
"
All specifically to do with exception safety.
Its mentioned in passing on at least two pages (links below) but lacking (as
far as I can see lacking a clear definition like this on the digital mars
web-site.
http://www.digitalmars.com/d/statement.htmlhttp://www.digitalmars.com/d/exception-safe.html

that has the same behavior but duplicates the end condition check.
This can be both a performance hit and can be really bad when the
condition changes or if it has side effects.

sugar either. Is this not what your syntactic sugar is supposed to
alias to? If not, then what? Repeating code that changes is as always
an issue but if its a complex condition it could (arguably should) be
a function instead.

no, the thought is that you can play games with what break does to get the
effect.
for(int i=5;i>0;i--)
{
...
goto breakpoint; //break;
}
ThisNeverRuns();
breakpoint:;
as for performance, there is none as the break is a "jump to the end" and
the result is a "jump to (a bit after) the end".
mixing several scope(last) and scope(break) could get fun though.

I like the idea of "do this then" versus "do this now". Its breaks out
of in the procedural (and even message passing OO style) where pretty
much everything is now but I'm not entirely convinced this is the best
way to express it. The body of a loop should have stuff to do with its
body only. A finally block is in the right place, at the end for
example (that's not to imply I like the earlier suggestion of adding
finally blocks to loops either).

after thinking of all the cases I'd want, I think that there is a place here
for something but if the structure isn't carefully considered, then it might
do more harm than good.