Thread overview | |||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
November 03, 2007 Ideas regarding flow control and loops | ||||
---|---|---|---|---|
| ||||
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 Re: Ideas regarding flow control and loops | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Aurélio | 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 Re: Ideas regarding flow control and loops | ||||
---|---|---|---|---|
| ||||
Posted in reply to downs | 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 Re: Ideas regarding flow control and loops | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Aurélio | 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 Re: Ideas regarding flow control and loops | ||||
---|---|---|---|---|
| ||||
Posted in reply to Charles D Hixson | 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 Re: Ideas regarding flow control and loops | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Keep | 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 Re: Ideas regarding flow control and loops | ||||
---|---|---|---|---|
| ||||
Posted in reply to downs | 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 Re: Ideas regarding flow control and loops | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Keep | 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 Re: Ideas regarding flow control and loops | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Aurélio | 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 Re: Ideas regarding flow control and loops | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Aurélio | 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.
|
Copyright © 1999-2021 by the D Language Foundation