• Bruce Adams <tortoise_74 yeah.who.co.uk> Nov 05 2007
• Bruce Adams <tortoise_74 yeah.who.co.uk> Nov 05 2007
• BCS <ao pathlink.com> Nov 05 2007

Bruce Adams <tortoise_74 yeah.who.co.uk> writes:

BCS Wrote:

 Bruce Adams wrote:
BCS Wrote:
Reply to Bruce,
BCS Wrote:




 Right. So what you really want is something that runs when the scope ends
naturally but not on a break.
 
 for(int i=5;i>0;i--)
 {
   ...
   break;
 }
 if (i<=0) ThisNeverRuns();
  
 


 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.


 
 
scope(skip):  - saves you one conditional - not very useful

if (!cond)
DoIfCondNeverPasses();
else do
{
...
}
while(cond);


mine looks better (IMHO)


 It doesn't justify a syntax change (IMHO)
  


 IIRC scope is totally redundant to begin with, your counter argument 
 apply to it's existing functionality but people still like it.


 
 
scope(break): - saves you a function call or two.

while(cond)
{
...
if (cond2) DoOnBreak(); break;
...
if (cond3) DoOnBreak(); break;
...
}


you prove half of my point and don't address the other half


 What was the other half again?
  
 


 Below
 
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.

Bruce Adams <tortoise_74 yeah.who.co.uk> writes:

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.html
http://www.digitalmars.com/d/exception-safe.html

BCS <ao pathlink.com> writes:

Reply to Bruce,

 BCS Wrote:
 
 Bruce Adams wrote:
 
 for(int i=5;i>0;i--)
 {
 ...
 break;
 }
 if (i<=0) ThisNeverRuns();


 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.

 
 Regards,
 
 Bruce.