Jump to page: 1 2 3
Thread overview
Ideas regarding flow control and loops
Nov 03, 2007
Marco Aurélio
Nov 03, 2007
downs
Nov 03, 2007
Daniel Keep
Nov 03, 2007
Marco Aurélio
Nov 03, 2007
downs
Nov 04, 2007
Robert Fraser
Nov 04, 2007
Marco Aurélio
Nov 04, 2007
downs
Nov 04, 2007
Bruce Adams
Nov 03, 2007
BCS
Nov 04, 2007
Bruce Adams
Nov 05, 2007
BCS
Nov 05, 2007
Bruce Adams
Nov 05, 2007
BCS
Nov 03, 2007
Marco Aurélio
Nov 03, 2007
Charles D Hixson
Nov 03, 2007
Marco Aurélio
Nov 04, 2007
Bruce Adams
Nov 05, 2007
BCS
Nov 05, 2007
Bruce Adams
Nov 04, 2007
Robert Fraser
November 03, 2007
Hello! I've been following the development of the D programming language for some time (around 1 year), and I have to say it keeps looking better.

I don't know if these have been proposed before, but I would like to make two suggestions regarding flow control and loops:

1- if behavior on "with" statement:

On the current specification of D, if you want to check if a class can be casted to a subclass, and do something with it, you have to do something like:

if (cast(Foo)bar)
    with(cast(Foo)bar)
    {
        DoSomething();
    }

While that works, it makes you have to write the same thing twice, and unless some compiler optimization kicks in (not sure if compilers check for that), the cast will have to be done twice. (and since it performs a runtime check, it will take some time) You could also use a temporary variable, but that wouldn't be so elegant.

My idea is to make the with statement also behave like an if statement, so the above code could be rewritten as only:

with(cast(Foo)bar)
{
    DoSomething();
}

There's the possibility this would make existing code slower, due to unnecessary checks for null (if you're not typecasting and are sure it's not null), so another possibility would be making the syntax like:

if with(cast(Foo)bar)
{
    DoSomething();
}

So the default "with" behavior would be preserved. Note that since it behaves like an if, you could add an else at the end, like:


if with(cast(Foo)bar)
{
    DoSomething();
} else {
    writeln("Not possible!");
}


2 - for .. finally, while .. finally:

This would allow having something like:

while(someCondition)
{
    DoSomething();
} finally {
    DoOtherThing();
}

The "finally" block would be called at the end of the repetition, only if no "break" was used. This may not seem useful at first, but I think can reduce the number of flags needed to implement various algorithms, making the code faster and more elegant. I'm not sure if this is already possible with scope guards.

That's it.. What do you think?
November 03, 2007
Marco Aurélio wrote:
> Hello! I've been following the development of the D programming language for some time (around 1 year), and I have to say it keeps looking better.
> 
> I don't know if these have been proposed before, but I would like to make two suggestions regarding flow control and loops:
> 
> 1- if behavior on "with" statement:

I used to have the same problem - I even wrote an ifIs template to get
around the repetition.
Then somebody clued me in to this:

if (auto foo=cast(Whee) bar) { /* use foo* }

ISN'T IT NEAT?
<3 D.

> 2 - for .. finally, while .. finally:
> 
> This would allow having something like:
> 
> while(someCondition)
> {
>     DoSomething();
> } finally {
>     DoOtherThing();
> }
> 
> The "finally" block would be called at the end of the repetition, only if no "break" was used. This may not seem useful at first, but I think can reduce the number of flags needed to implement various algorithms, making the code faster and more elegant. I'm not sure if this is already possible with scope guards.
> 
I like that. :) vote +1
 --downs
November 03, 2007

downs wrote:
> Marco Aurélio wrote:
>> Hello! I've been following the development of the D programming language for some time (around 1 year), and I have to say it keeps looking better.
>>
>> I don't know if these have been proposed before, but I would like to make two suggestions regarding flow control and loops:
>>
>> 1- if behavior on "with" statement:
> 
> I used to have the same problem - I even wrote an ifIs template to get
> around the repetition.
> Then somebody clued me in to this:
> 
> if (auto foo=cast(Whee) bar) { /* use foo* }
> 
> ISN'T IT NEAT?
> <3 D.

Oh hell yeah.

>> 2 - for .. finally, while .. finally:
>>
>> This would allow having something like:
>>
>> while(someCondition)
>> {
>>     DoSomething();
>> } finally {
>>     DoOtherThing();
>> }
>>
>> The "finally" block would be called at the end of the repetition, only if no "break" was used. This may not seem useful at first, but I think can reduce the number of flags needed to implement various algorithms, making the code faster and more elegant. I'm not sure if this is already possible with scope guards.
>>
> I like that. :) vote +1
>  --downs

else would also be nice.

foreach( foo ; bar )
  DoSomethingWith(foo);

finally
  DoSomethingAfterwards();

else
  DoSomethingElseSinceBarIsEmpty();

But maybe that's just me.

	-- Daniel
November 03, 2007
Marco Aurélio wrote:
> Hello! I've been following the development of the D programming language for some time (around 1 year), and I have to say it keeps looking better.
> ...
> 2 - for .. finally, while .. finally:
> 
> This would allow having something like:
> 
> while(someCondition)
> {
>     DoSomething();
> } finally {
>     DoOtherThing();
> }
> 
> The "finally" block would be called at the end of the repetition, only if no "break" was used. This may not seem useful at first, but I think can reduce the number of flags needed to implement various algorithms, making the code faster and more elegant. I'm not sure if this is already possible with scope guards.
> 
> That's it.. What do you think?

No.  Finally should be the label on a block of code that will be executed *WHATEVER* happens in the preceding loop, including the raising of an exception.
November 03, 2007
Charles D Hixson Wrote:

> No.  Finally should be the label on a block of code that will be executed *WHATEVER* happens in the preceding loop, including the raising of an exception.

Hmm Yeah, now that I think about it, having it on that way would make it inconsistent with the try-catch-finally behavior... Maybe adding another keyword? or something like:

for(int i = 0; i < 30; i++)
{
    if (something)
        break;
} catch (break) {
    Foo();
}
November 03, 2007
Daniel Keep Wrote:
> else would also be nice.

This would be specially usefull for implementing collisions on 2D games with bitmap-based coldefs, something along the lines of:

while(object.isCollidingWithGround())
{
     object.moveUp();
} finally {
     object.stop();
} else {
     object.applyGravity();
}

While the object is colliding with the ground, move it up... Then stop it.. and if he wasn't colliding with the ground in the first place, apply gravity.
November 03, 2007
downs Wrote:

> if (auto foo=cast(Whee) bar) { /* use foo* }
> 
> ISN'T IT NEAT?
> <3 D.

Indeed. Even better:

if (auto bar = cast(Whee) bar) { }

So the variable bar of type "Whee" would hide the other variable bar at the local scope.

But I still think it would be usefull to have the if+with statement.
November 03, 2007
Reply to Daniel,

> downs wrote:
> 
>> Marco Aurélio wrote:
>> 
>>> 2 - for .. finally, while .. finally:
>>> 
>>> This would allow having something like:
>>> 
>>> while(someCondition)
>>> {
>>> DoSomething();
>>> } finally {
>>> DoOtherThing();
>>> }
>>> The "finally" block would be called at the end of the repetition,
>>> only if no "break" was used. This may not seem useful at first, but
>>> I think can reduce the number of flags needed to implement various
>>> algorithms, making the code faster and more elegant. I'm not sure if
>>> this is already possible with scope guards.
>>> 
>> I like that. :) vote +1
>> --downs
> else would also be nice.
> 
> foreach( foo ; bar )
> DoSomethingWith(foo);
> finally
> DoSomethingAfterwards();
> else
> DoSomethingElseSinceBarIsEmpty();
> But maybe that's just me.
> 
> -- Daniel
> 


I'd rather an extension of the scope syntax

while(cond)
{
  scope(last) DoOnCondFailed();
  scope(break) DoOnBreak(); // or any explicet quit
  scope(skip) DoIfCondNeverPasses();
  scope(first) goto SkipSomeStuff;
  ...
}


November 03, 2007
Marco Aurélio wrote:
> Daniel Keep Wrote:
>> else would also be nice.
> 
> This would be specially usefull for implementing collisions on 2D games with bitmap-based coldefs, something along the lines of:
> 
> while(object.isCollidingWithGround())
> {
>      object.moveUp();
> } finally {
>      object.stop();
> } else {
>      object.applyGravity();
> }
> 
> While the object is colliding with the ground, move it up... Then stop it.. and if he wasn't colliding with the ground in the first place, apply gravity.

Well, technically ...
 --downs

PS:
module test17;
import std.stdio;

void extwhile(lazy bool cond, void delegate() Body, void delegate()
Finally, void delegate() Else) {
  if (!cond()) Else();
  else {
    do Body(); while (cond());
    Finally();
  }
}

void main() {
  bool colliding=true;
  int counter=0;
  extwhile(colliding,
    { writefln("Still colliding"); counter++; if (counter==3)
colliding=false; },
    { writefln("Done colliding"); },
    { writefln("Never collided"); }
  );
}
November 04, 2007
Marco Aurélio Wrote:

> 2 - for .. finally, while .. finally:
> 
> This would allow having something like:
> 
> while(someCondition)
> {
>     DoSomething();
> } finally {
>     DoOtherThing();
> }
> 
> The "finally" block would be called at the end of the repetition, only if no "break" was used. This may not seem useful at first, but I think can reduce the number of flags needed to implement various algorithms, making the code faster and more elegant. I'm not sure if this is already possible with scope guards.
> 
> That's it.. What do you think?

Another "eh"... I just can't see its limited use justifying the added complexity.

« First   ‹ Prev
1 2 3