Digital Mars - digitalmars.D - DMD 0.148

On Sun, 26 Feb 2006 13:06:36 +1100, Walter Bright  
<newshound digitalmars.com> wrote:

 Scope guards are a novel feature no other language has. They're based on
 Andrei Alexandrescu's scope guard macros, which have led to considerable
 interest in the idea. Check out the article
 www.digitalmars.com/d/exception-safe.html


Wow! I know of one other language that (almost) implements this.

Does 'scope' mean any type scope, and not just function scope? For  
example, can it include module scope? ... if/while/for/foreach scope? ...  
block scope?

And I assume 'statement' can be a block of statements ...

     on_exit_scope { stmt1; stmt2; ... stmtn;}

-- 
Derek Parnell
Melbourne, Australia

Feb 25 2006

↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:

"Derek Parnell" <derek psych.ward> wrote in message 
news:op.s5j942tp6b8z09 ginger.vic.bigpond.net.au...
 Wow! I know of one other language that (almost) implements this.


Which one?

 Does 'scope' mean any type scope, and not just function scope? For 
 example, can it include module scope? ... if/while/for/foreach scope? ... 
 block scope?


Yes.

 And I assume 'statement' can be a block of statements ...

     on_exit_scope { stmt1; stmt2; ... stmtn;}


Yup. (The C++ macro version is limited to a single function call with 
argument.)

Feb 25 2006

↑ ↓ ← → Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:

Walter Bright wrote:
 "Derek Parnell" <derek psych.ward> wrote in message 
 news:op.s5j942tp6b8z09 ginger.vic.bigpond.net.au...
 Does 'scope' mean any type scope, and not just function scope? For 
 example, can it include module scope? ... if/while/for/foreach scope? ... 
 block scope?


 Yes.
 


On module scope? No, it doesn't actually work on module scope, right? 
Wouldn't make sense, as a module scope is a declaration scope, and not a 
instruction scope/block.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."

Feb 27 2006

↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:

"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
news:dtvcoj$225e$1 digitaldaemon.com...
 Walter Bright wrote:
 "Derek Parnell" <derek psych.ward> wrote in message 
 news:op.s5j942tp6b8z09 ginger.vic.bigpond.net.au...
 Does 'scope' mean any type scope, and not just function scope? For 
 example, can it include module scope? ... if/while/for/foreach scope? 
 ... block scope?


 Yes.


 On module scope? No, it doesn't actually work on module scope, right? 
 Wouldn't make sense, as a module scope is a declaration scope, and not a 
 instruction scope/block.


That's right. You can't have statements in module scope, so there's no way 
to apply it to module scope. Or class scope. Or any other place where 
statements are not allowed.

Feb 27 2006

↑ ↓ ← → "Andrew Fedoniouk" <news terrainformatica.com> writes:

"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dtr8kl$4lm$1 digitaldaemon.com...
 "Derek Parnell" <derek psych.ward> wrote in message 
 news:op.s5j942tp6b8z09 ginger.vic.bigpond.net.au...
 Wow! I know of one other language that (almost) implements this.


 Which one?


If I understand this correctly Ruby has something similar
http://www.rubycentral.com/book/tut_exceptions.html

But this is the same try-catch-finally I guess
as these on_scope_*** too, btw.

Andrew.

Feb 27 2006

↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:

"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:dtvkhr$2cf4$1 digitaldaemon.com...
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:dtr8kl$4lm$1 digitaldaemon.com...
 "Derek Parnell" <derek psych.ward> wrote in message 
 news:op.s5j942tp6b8z09 ginger.vic.bigpond.net.au...
 Wow! I know of one other language that (almost) implements this.


 Which one?


 If I understand this correctly Ruby has something similar
 http://www.rubycentral.com/book/tut_exceptions.html

 But this is the same try-catch-finally I guess
 as these on_scope_*** too, btw.


Ruby's rescue thing looks like try-catch. on_scope is much more than 
try-catch, or I wouldn't have implemented it <g>.

Feb 27 2006

↑ ↓ ← → Mike Capp <mike.capp gmail.com> writes:

In article <du0slm$lj0$2 digitaldaemon.com>, Walter Bright says...
Ruby's rescue thing looks like try-catch. on_scope is much more than 
try-catch, or I wouldn't have implemented it <g>. 


on_scope is quite cute, and certainly cleaner than the C++ implementation of
ScopeGuard. Compared to ctor/dtor RAII, though, it still has the same problem as
try-catch{-finally} - a naive use of a resource is wrong by default, and the
programmer has to do something extra to make it right.

When I first saw Andrei's paper it struck me that what made things painful in
C++ was the lack of usable closures. Since D is pretty good in this regard,
could the same effect have been achieved with a less sugary but more regular
approach reusing RAII-auto syntax, e.g.

# import std.scopeguard;
# auto Guard onOk = new OnScopeSuccessGuard(&mySuccessFunc);
# auto Guard onFail = new OnScopeFailureGuard(function { /* ad hoc code */ });

with something like C++'s std::uncaught_exception in the Guard subclass
destructor implementations to discriminate exit conditions?

cheers
Mike

Feb 28 2006

↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:

"Mike Capp" <mike.capp gmail.com> wrote in message 
news:du1ire$1h1s$1 digitaldaemon.com...
 When I first saw Andrei's paper it struck me that what made things painful 
 in
 C++ was the lack of usable closures. Since D is pretty good in this 
 regard,
 could the same effect have been achieved with a less sugary but more 
 regular
 approach reusing RAII-auto syntax, e.g.

 # import std.scopeguard;
 # auto Guard onOk = new OnScopeSuccessGuard(&mySuccessFunc);
 # auto Guard onFail = new OnScopeFailureGuard(function { /* ad hoc code 
 */ });

 with something like C++'s std::uncaught_exception in the Guard subclass
 destructor implementations to discriminate exit conditions?


I don't know a way to make that work as cleanly.

Feb 28 2006

↑ ↓ ← → Tom <Tom_member pathlink.com> writes:

In article <dtr2fg$2vqr$4 digitaldaemon.com>, Walter Bright says...
Scope guards are a novel feature no other language has. They're based on 
Andrei Alexandrescu's scope guard macros, which have led to considerable 
interest in the idea. Check out the article 
www.digitalmars.com/d/exception-safe.html


Again the release is very nice!

A question: I seemed to miss the scope guard discussion (whatever). Can you
enlighten me with an example (or guide me with a link) to illustrate the
usefulness of this feature?

Thanks,

P.S.: In the new docs for the scope guard stuff there is a TYPO at "[snip] close
of the scope, they also are interleaved with the OnScopeStatements in the
reverse *lexeical* order in which they appear."

Tom;

Feb 25 2006

↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:

"Tom" <Tom_member pathlink.com> wrote in message 
news:dtrakc$6lo$1 digitaldaemon.com...
 A question: I seemed to miss the scope guard discussion (whatever). Can 
 you
 enlighten me with an example (or guide me with a link) to illustrate the
 usefulness of this feature?


This article has some good examples: 
www.digitalmars.com/d/exception-safe.html
Also, do a google groups search on "Alexandrescu on_scope_exit" for a good 
thread on it.

 Thanks,

 P.S.: In the new docs for the scope guard stuff there is a TYPO at "[snip] 
 close
 of the scope, they also are interleaved with the OnScopeStatements in the
 reverse *lexeical* order in which they appear."


Thanks, I'll fix it.

Feb 25 2006

↑ ↓ ← → Hasan Aljudy <hasan.aljudy gmail.com> writes:

Walter Bright wrote:
 "John Reimer" <terminal.node gmail.com> wrote in message 
 news:dtrg0e$c9k$1 digitaldaemon.com...
 
Nice feature, but rather ugly to look at; although, I'm not sure how 
something like that could be made to look pretty.


 
 I think it's ugly, too, but I just couldn't come up with anything 
 significantly better.
 
 
Nonetheless the scope guard looks like something I should read up on.

Thanks for another good release.


 
 You're welcome. 
 
 


Why not just reuse "finally"?

void func()
{
     init_some_reource();
     foo(); // foo throws an exception
     //func doesn't catch the exception
     //but it has a finally clause

     finally  //aka on scope exit, whether success or fail
     {
         release_the_resource();
     }
}

Feb 26 2006

↑ ↓ ← → Miles <_______ _______.____> writes:

Walter Bright wrote:
 finally does work for on_scope_exit, but it leaves on_scope_success and 
 on_scope_failure hanging. 


on_scope_exit    -> finally { ... }
on_scope_success -> finally(true) { ... }
on_scope_failure -> finally(false) { ... }

on_scope_exit    -> finally { ... }
on_scope_success -> finally(success) { ... }
on_scope_failure -> finally(failure) { ... }

on_scope_exit    -> finally { ... }
on_scope_success -> finally("success") { ... }
on_scope_failure -> finally("failure") { ... }

on_scope_exit    -> finally { ... }
on_scope_success -> finally return { ... }
on_scope_failure -> finally throw { ... }

Feb 26 2006

↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:

"Miles" <_______ _______.____> wrote in message 
news:dtu8ic$i0t$1 digitaldaemon.com...
 Walter Bright wrote:
 finally does work for on_scope_exit, but it leaves on_scope_success and
 on_scope_failure hanging.


 on_scope_exit    -> finally { ... }
 on_scope_success -> finally(true) { ... }
 on_scope_failure -> finally(false) { ... }

 on_scope_exit    -> finally { ... }
 on_scope_success -> finally(success) { ... }
 on_scope_failure -> finally(failure) { ... }

 on_scope_exit    -> finally { ... }
 on_scope_success -> finally("success") { ... }
 on_scope_failure -> finally("failure") { ... }

 on_scope_exit    -> finally { ... }
 on_scope_success -> finally return { ... }
 on_scope_failure -> finally throw { ... }


I don't think those are much better :-(

Feb 26 2006

↑ ↓ ← → Wang Zhen <nehzgnaw gmail.com> writes:

Walter Bright wrote:
 "Miles" <_______ _______.____> wrote in message 
 news:dtu8ic$i0t$1 digitaldaemon.com...
 
Walter Bright wrote:

finally does work for on_scope_exit, but it leaves on_scope_success and
on_scope_failure hanging.


on_scope_exit    -> finally { ... }
on_scope_success -> finally(true) { ... }
on_scope_failure -> finally(false) { ... }

on_scope_exit    -> finally { ... }
on_scope_success -> finally(success) { ... }
on_scope_failure -> finally(failure) { ... }

on_scope_exit    -> finally { ... }
on_scope_success -> finally("success") { ... }
on_scope_failure -> finally("failure") { ... }

on_scope_exit    -> finally { ... }
on_scope_success -> finally return { ... }
on_scope_failure -> finally throw { ... }


 
 I don't think those are much better :-( 
 
 


How about
on_scope_exit -> scope exit
on_scope_success -> scope success
on_scope_failure -> scope failure
?

on_prefixed_underscore_separated_keywords just look obtrusive in D code.

Feb 27 2006

↑ ↓ ← → "Lionello Lunesu" <lio remove.lunesu.com> writes:

"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dtsr1i$1u4v$4 digitaldaemon.com...
 "Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message 
 news:dtsfm5$1h2i$1 digitaldaemon.com...
 Why not just reuse "finally"?

 void func()
 {
     init_some_reource();
     foo(); // foo throws an exception
     //func doesn't catch the exception
     //but it has a finally clause

     finally  //aka on scope exit, whether success or fail
     {
         release_the_resource();
     }
 }


 finally does work for on_scope_exit, but it leaves on_scope_success and 
 on_scope_failure hanging.


Similar to allowing multiple "finally" statements, even without "try", you 
could allow multiple "catch", also without "try":

finally writefln("done");
dofoo();
catch dofoo_undo();
dobar();

where the catch would also rethrow the exception being caught.

Now we just need something sensible for on_scope_success and we're done ; )

L.

Feb 27 2006

↑ ↓ ← → Hasan Aljudy <hasan.aljudy gmail.com> writes:

Walter Bright wrote:
 "Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message 
 news:dtsfm5$1h2i$1 digitaldaemon.com...
 
Why not just reuse "finally"?

void func()
{
    init_some_reource();
    foo(); // foo throws an exception
    //func doesn't catch the exception
    //but it has a finally clause

    finally  //aka on scope exit, whether success or fail
    {
        release_the_resource();
    }
}


 
 finally does work for on_scope_exit, but it leaves on_scope_success and 
 on_scope_failure hanging. 
 
 


Why do we need to handle "on failure" and "on success" any differently 
than a regular scope exit?

Feb 27 2006

↑ ↓ ← → "Unknown W. Brackets" <unknown simplemachines.org> writes:

Honestly, as ugly as the syntax is, I must admit I like the grouping of 
the start and end conditions together.

That's one thing I've always thought strange about programming; people 
talk about functions and classes and all the different aesthetic and 
linear/non-linear relationships between them, but in the end it is all 
completely and totally linear, when for many cases that doesn't make sense.

-[Unknown]


 Walter Bright wrote:
 "John Reimer" <terminal.node gmail.com> wrote in message 
 news:dtrg0e$c9k$1 digitaldaemon.com...

 Nice feature, but rather ugly to look at; although, I'm not sure how 
 something like that could be made to look pretty.



 I think it's ugly, too, but I just couldn't come up with anything 
 significantly better.


 Nonetheless the scope guard looks like something I should read up on.

 Thanks for another good release.



 You're welcome.


 Why not just reuse "finally"?
 
 void func()
 {
     init_some_reource();
     foo(); // foo throws an exception
     //func doesn't catch the exception
     //but it has a finally clause
 
     finally  //aka on scope exit, whether success or fail
     {
         release_the_resource();
     }
 }

Feb 26 2006

↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:

"Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
news:dtstki$20os$1 digitaldaemon.com...
 Honestly, as ugly as the syntax is, I must admit I like the grouping of 
 the start and end conditions together.

 That's one thing I've always thought strange about programming; people 
 talk about functions and classes and all the different aesthetic and 
 linear/non-linear relationships between them, but in the end it is all 
 completely and totally linear, when for many cases that doesn't make 
 sense.


Consider the for loop:

    for (expr; expr; expr)

The 3rd expression is executed at the *end* of the loop, yet it is placed at 
the beginning. So there is precedent for the utility of putting code where 
it conceptually belongs rather than where it is executed.

Feb 26 2006

↑ ↓ ← → "Unknown W. Brackets" <unknown simplemachines.org> writes:

I'm not at all disagreeing; but aside from language constructs like 
looping, which seem to be (in my experience) the easiest thing to get a 
good grasp on for newcomers, there aren't many ways in which (general) 
programming is non-linear.

I am saying this is strange; tasks, in many cases, are not linear. 
Obviously it must map well to something the computer understands, but 
that can often be handled by the compiler (as in this case.)

For example, academic programming typically teaches that multiple 
returns in a function are evil.  This is because it is mixing non linear 
programming (not returning always at the very end) with linear programming.

Scope exit and such cases are a good example of a clean way to resolve 
this problem without saying that "returns and continues are evil." What 
more, they are logical.

-[Unknown]


 Consider the for loop:
 
     for (expr; expr; expr)
 
 The 3rd expression is executed at the *end* of the loop, yet it is placed at 
 the beginning. So there is precedent for the utility of putting code where 
 it conceptually belongs rather than where it is executed.

Feb 26 2006

↑ ↓ ← → Kyle Furlong <kylefurlong gmail.com> writes:

John Reimer wrote:
 Walter Bright wrote:
 Scope guards are a novel feature no other language has. They're based 
 on Andrei Alexandrescu's scope guard macros, which have led to 
 considerable interest in the idea. Check out the article 
 www.digitalmars.com/d/exception-safe.html


 
 Nice feature, but rather ugly to look at; although, I'm not sure how 
 something like that could be made to look pretty.  Nonetheless the scope 
 guard looks like something I should read up on.
 
 Thanks for another good release.
 
 -JJR


I thought the same, perhaps the "scope" portion is understood? So that the
keywords become: onsuccess, onfailure, ...?

Feb 25 2006

↑ ↓ ← → John Reimer <terminal.node gmail.com> writes:

Nick wrote:
 In article <dtri4j$ejs$1 digitaldaemon.com>, Kyle Furlong says...
 I thought the same, perhaps the "scope" portion is understood? So that the
 keywords become: onsuccess, onfailure, ...?


 Personally I think it's better not to overuse simple words and phrases as
 keywords. onsuccess/onSuccess etc. are a bit too likely to be chosen as a
 function name, especially since these are not common keywords in other
 languages.
 
 Nick
 
 



I have to agree with this.  The "scope" prefix, however unsightly, 
serves its purpose here.  Yet I wonder if there is a way to improve upon 
that syntax.

-JJR

Feb 26 2006

↑ ↓ ← → Cris <central_p hotmail.com> writes:

Yes I agree with Kyle but not to overuse simple keywords, what about 
something like "onSuccess:", "onFailure:", etc...

To me all "_" look ugly. Perhaps the author could ask the community for 
suggestions when naming new features?
Or perhaps just "onScopeSuccess", "onScopeFailure"...

Kyle Furlong wrote:
 John Reimer wrote:
 Walter Bright wrote:
 Scope guards are a novel feature no other language has. They're based 
 on Andrei Alexandrescu's scope guard macros, which have led to 
 considerable interest in the idea. Check out the article 
 www.digitalmars.com/d/exception-safe.html



 Nice feature, but rather ugly to look at; although, I'm not sure how 
 something like that could be made to look pretty.  Nonetheless the 
 scope guard looks like something I should read up on.

 Thanks for another good release.

 -JJR


 I thought the same, perhaps the "scope" portion is understood? So that 
 the keywords become: onsuccess, onfailure, ...?

Feb 26 2006

↑ ↓ ← → Tom S <h3r3tic remove.mat.uni.torun.pl> writes:

Cris wrote:
 
 Yes I agree with Kyle but not to overuse simple keywords, what about 
 something like "onSuccess:", "onFailure:", etc...


Then it would look like an ordinary label, wouldn't it ? That's a 
different thing.


 To me all "_" look ugly. Perhaps the author could ask the community for 
 suggestions when naming new features?
 Or perhaps just "onScopeSuccess", "onScopeFailure"...


And these don't stand out enough IMO



-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O 
!M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

Feb 26 2006

↑ ↓ ← → Cris <central_p hotmail.com> writes:

Tom S wrote:
 Cris wrote:
 Yes I agree with Kyle but not to overuse simple keywords, what about 
 something like "onSuccess:", "onFailure:", etc...


 Then it would look like an ordinary label, wouldn't it ? That's a 
 different thing.


Are there labels in D?


 
 
 To me all "_" look ugly. Perhaps the author could ask the community 
 for suggestions when naming new features?
 Or perhaps just "onScopeSuccess", "onScopeFailure"...


 And these don't stand out enough IMO
 
 
 



I don't say my suggestions are the best :) you can always suggest 
something better.

Feb 26 2006

↑ ↓ ← → Chris Sauls <ibisbasenji gmail.com> writes:

Cris wrote:
 Tom S wrote:
 Cris wrote:
 Yes I agree with Kyle but not to overuse simple keywords, what about 
 something like "onSuccess:", "onFailure:", etc...


 different thing.




Yup.  As free labels and as block statement labels.

# import std.stdio;
# void main () {
#   goto L_bar;
#
# L_foo:
#   writefln("foo"c);
#   goto L_exit;
#
# L_bar:
#   writefln("bar"c);
#   goto L_foo;
#
# L_exit:
# }

-- Chris Nicholson-Sauls

Feb 26 2006

↑ ↓ ← → =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:

On Sat, 25 Feb 2006 18:06:36 -0800, Walter Bright wrote:

 Scope guards are a novel feature no other language has. They're based on 
 Andrei Alexandrescu's scope guard macros, which have led to considerable 
 interest in the idea. Check out the article 
 www.digitalmars.com/d/exception-safe.html


Thanks Walter very cool.

I like kyle's suggestion on using.
onExit, onFailure, onSuccess so that it looks a little like javascript. 


Walter have you considered like publishing new releases on
http://freshmeat.net ??

Like GDC and DStress do ??

Freshmeat is the slashdot equivalent for software.

Knud

Feb 26 2006

↑ ↓ ← → James Dunne <james.jdunne gmail.com> writes:

Derek Parnell wrote:
 On Sun, 26 Feb 2006 19:41:14 +1100, bobef <bobef lessequal.com> wrote:
 
 Knud Sørensen wrote:

 Freshmeat is the slashdot equivalent for software.



 Forgive my ignorance, but what is slashdot?


 
 It's the equvalent of FreshMeat for I.T. related news and gosip.
 


That's a nice, circular definition. =P

What's a square?

Well, it's like a rectangle but with even sides.

What's a rectangle?

Well, it's like a square but only opposite side pairs need to be the 
same length.

-- 
Regards,
James Dunne

Feb 26 2006

↑ ↓ ← → Hasan Aljudy <hasan.aljudy gmail.com> writes:

Thomas Kuehne wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 bobef schrieb am 2006-02-26:
 
Knud S�rensen wrote:


Freshmeat is the slashdot equivalent for software.


Forgive my ignorance, but what is slashdot?


 
 http://slashdot.org
 
 Thomas
 
 
 -----BEGIN PGP SIGNATURE-----
 
 iD8DBQFEAX4/3w+/yD4P9tIRAjvuAJwPvtROSVZvxhiVZkzrJK+5zq2hDQCeI3Bt
 ThkzHvadOtJAdWlCXR6c6zc=
 =sWOz
 -----END PGP SIGNATURE-----


Still, what is it? I've been there before .. didn't quite get it. Why is 
it so popular?!

Feb 26 2006

↑ ↓ ← → Kevin Bealer <Kevin_member pathlink.com> writes:

In article <dtsgcf$1i3q$1 digitaldaemon.com>, Hasan Aljudy says...
Thomas Kuehne wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 bobef schrieb am 2006-02-26:
 
Knud S�rensen wrote:


Freshmeat is the slashdot equivalent for software.


Forgive my ignorance, but what is slashdot?


 
 http://slashdot.org
 
 Thomas
 
 
 -----BEGIN PGP SIGNATURE-----
 
 iD8DBQFEAX4/3w+/yD4P9tIRAjvuAJwPvtROSVZvxhiVZkzrJK+5zq2hDQCeI3Bt
 ThkzHvadOtJAdWlCXR6c6zc=
 =sWOz
 -----END PGP SIGNATURE-----


Still, what is it? I've been there before .. didn't quite get it. Why is 
it so popular?!


It's technology and scientific news and covers a lot of 'nerd' interest stuff;
it's highly configurable if you have an account.

Every article has free-form user comments and discussion, which means you not
only see the news article, but can pick up dozens of links to related info, get
opinions on both sides, etc.  (Many of the participants are highly uninformed,
but that is hard to avoid on the web...)

It's news, discussion, conversation, and a sort of "commonwealth" community, and
each discussion is anchored off of a "real" news article, book review, or
writeup, usually somewhere else.  In this way its like a mixture of newsgroup
discussions, journalism, and wiki-like community authoring.

Like almost all human communities, the appeal is determined mostly by the types
of people that exist there (i.e. prisons versus country clubs versus rock
concerts).  So its probably very grating if you don't like techie/trekkie/IT
types.

[But it's starting to look commonplace now because everyone copied them.  Every
revolution is unthinkable beforehand and obvious afterwards...]

Kevin

Feb 28 2006

↑ ↓ ← → Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:

Walter Bright wrote:

 Scope guards are a novel feature no other language has. They're based on
 Andrei Alexandrescu's scope guard macros, which have led to considerable
 interest in the idea. Check out the article
 www.digitalmars.com/d/exception-safe.html


Concept is really promising. Syntax ... well ... :D

I try to come with some other syntaxs.

ORYGINAL:

void LongFunction()
{
    State save = UIElement.GetState();
    on_scope_success UIElement.SetState(save);
    on_scope_failure UIElement.SetState(Failed(save));
    ...lots of code...
}

Why not:


VERSION A:
void LongFunction()
{
    State save = UIElement.GetState();
    on (success) {
         UIElement.SetState(save)
    }
    on (failure) {
        UIElement.SetState(Failed(save))
    }
    ...lots of code...
}

(not that success and failure could be recognized only as "on" keyword's
argument.)


VERSION B:
void LongFunction()
{
    State save = UIElement.GetState();
    scope (success) {
        UIElement.SetState(save);
    }
    scope (failure) {
        UIElement.SetState(Failed(save));
    }
    ...lots of code...
}

VERSION C:
void LongFunction()
{
    State save = UIElement.GetState();
    scope_success UIElement.SetState(save);
    scope_failure UIElement.SetState(Failed(save));
    ...lots of code...
}


What do you think? Maybe later we'll come with better ideas.

Feb 26 2006

↑ ↓ ← → Kyle Furlong <kylefurlong gmail.com> writes:

Dawid Ciężarkiewicz wrote:
 Dawid Ciężarkiewicz wrote:
 VERSION E:
 void LongFunction()
 {
 State save = UIElement.GetState();
 onscope {
         case success: UIElement.SetState(save);
     }
 onscope {
         case failure: UIElement.SetState(Failed(save));
     }
 ...lots of code...
 }


 Just came to my mind:
 
 This version is especially neat because it may be simplified to:
 void LongFunction()
 {
     State save = UIElement.GetState();
     onscope {
         case success: UIElement.SetState(save); break;
         case failure: UIElement.SetState(Failed(save));
     }
     ...lots of code...
 }


I really like this idea, cons anyone?

Feb 26 2006

↑ ↓ ← → James Dunne <james.jdunne gmail.com> writes:

Kyle Furlong wrote:
 Dawid Ciężarkiewicz wrote:
 
 Dawid Ciężarkiewicz wrote:

 VERSION E:
 void LongFunction()
 {
 State save = UIElement.GetState();
 onscope {
         case success: UIElement.SetState(save);
     }
 onscope {
         case failure: UIElement.SetState(Failed(save));
     }
 ...lots of code...
 }



 Just came to my mind:

 This version is especially neat because it may be simplified to:
 void LongFunction()
 {
     State save = UIElement.GetState();
     onscope {
         case success: UIElement.SetState(save); break;
         case failure: UIElement.SetState(Failed(save));
     }
     ...lots of code...
 }


 
 I really like this idea, cons anyone?


I don't like the words 'success' and 'failure' used all over the place. 
  The meaning of the function's success isn't based on only if no 
exceptions were thrown.  Similarly, the function doesn't have to 'fail' 
if an exception were thrown.

I think they should be renamed to represent what they actually do.  That 
is, 'no exception thrown'/'pass', 'exception thrown'/'catch', 'scope 
exited'/'exit'.  Also, I think it would be more pleasing to the eye (and 
the maintainer) if the effect of the scope guard were more obvious in 
the code.  Something like:

void LongFunction()
{
     scope (State save = UIElement.GetState())
     catch {
         UIElement.SetState(Failed(save));
     }
     pass {
         UIElement.SetState(save);
     }
     body {
         ... lots of code ...
     }
}

This way, it looks like a function contract, except it applies to any 
scope.  The catch block is reused but only for purposes of noting that 
there was an exception caught.  The pass block is quite simply the 
'else' to the catch block, and should happen only if no exceptions were 
caught.  Furthermore, there could be a general 'exit' block.

One could add as many of these blocks as necessary, and the compiler 
will guarantee to call them in order of definition, much like the 
original solution but not requiring one to think backwards.

bool LongFunction()
{
     bool  passed = false;

     scope (State save = UIElement.GetState())
     catch { UIElement.SetState(Failed(save)); writef('0'); }
     pass { UIElement.SetState(save); writef('1'); }
     pass { passed = true; writef('2'); }
     body {
         ... lots of code ...
     }
     exit { writef('3'); }

     return passed;
}

So, if an exception were thrown in '... lots of code ...', you'd see 
'03' and the function would return false.  However, if no exception were 
thrown you'd see '123' and the function would return true.  This 
demonstrates the order of execution across multiple blocks.  In this 
example, the order of the 'exit' block relative to the 'catch' and 
'pass' blocks is important.

Consequently, I don't think the order of the 'body' block should matter 
at all, relative to the other blocks; and it should be fixed to only 
allow one instance of it.  Then, it is a matter of personal/project 
style where the 'body' block would fall.

Thoughts on this?

One last thought I had was to remove the parenthesized expression form 
of scope (expr) ... and use another block name to represent the 
initialization stage, just to be consistent.

-- 
Regards,
James Dunne

Feb 26 2006

↑ ↓ ← → =?UTF-8?B?SnVsaW8gQ8Opc2FyIENhcnJhc2NhbCBVcnF1aWpv?= writes:

James Dunne wrote:
 Kyle Furlong wrote:
 bool LongFunction()
 {
     bool  passed = false;
 
     scope (State save = UIElement.GetState())
     catch { UIElement.SetState(Failed(save)); writef('0'); }
     pass { UIElement.SetState(save); writef('1'); }
     pass { passed = true; writef('2'); }
     body {
         ... lots of code ...
     }
     exit { writef('3'); }
 
     return passed;
 }


This is the best I've seen but:

- Why two "pass" blocks?.
- About "exit" would be better before the "body" block and maybe replace 
it with "finally" to save one more keyword.

I'm also assuming that we could also do one liners without the braces:


bool LongFunction()
{
     bool  passed = false;

     scope State save = UIElement.GetState();
     catch UIElement.SetState(Failed(save));
     pass UIElement.SetState(save);
     finally writef('3');
     body {
         ... lots of code ...
     }

     return passed;
  }

Feb 26 2006

↑ ↓ ← → James Dunne <james.jdunne gmail.com> writes:

Julio César Carrascal Urquijo wrote:
 James Dunne wrote:
 
 Kyle Furlong wrote:
 bool LongFunction()
 {
     bool  passed = false;

     scope (State save = UIElement.GetState())
     catch { UIElement.SetState(Failed(save)); writef('0'); }
     pass { UIElement.SetState(save); writef('1'); }
     pass { passed = true; writef('2'); }
     body {
         ... lots of code ...
     }
     exit { writef('3'); }

     return passed;
 }


 
 This is the best I've seen but:
 
 - Why two "pass" blocks?.


Just to demonstrate that the ordering of the blocks matters, and that 
multiple blocks can be defined.

 - About "exit" would be better before the "body" block and maybe replace 
 it with "finally" to save one more keyword.


I noted this was a matter of personal style where the body block goes, 
as it does not depend on the order of the other blocks.  Personally, I 
like seeing the exit block after the body, as it should flow naturally.

 
 I'm also assuming that we could also do one liners without the braces:
 
 
 bool LongFunction()
 {
     bool  passed = false;
 
     scope State save = UIElement.GetState();
     catch UIElement.SetState(Failed(save));
     pass UIElement.SetState(save);
     finally writef('3');
     body {
         ... lots of code ...
     }
 
     return passed;
  }


Sure, why not?

-- 
Regards,
James Dunne

Feb 26 2006

↑ ↓ ← → Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:

James Dunne wrote:
 I don't like the words 'success' and 'failure' used all over the place.


Yes. I have to agree they are little missused. Changing them to "pass" as
success, "fail"/"catch" as "failure" and "default" as exit is good idea.

 void LongFunction()
 {
      scope (State save = UIElement.GetState())
      catch {
          UIElement.SetState(Failed(save));
      }
      pass {
          UIElement.SetState(save);
      }
      body {
          ... lots of code ...
      }
 }
 
 This way, it looks like a function contract, except it applies to any
 scope.  The catch block is reused but only for purposes of noting that
 there was an exception caught.  The pass block is quite simply the
 'else' to the catch block, and should happen only if no exceptions were
 caught.  Furthermore, there could be a general 'exit' block.
 
 One could add as many of these blocks as necessary, and the compiler
 will guarantee to call them in order of definition, much like the
 original solution but not requiring one to think backwards.
 
 bool LongFunction()
 {
      bool  passed = false;
 
      scope (State save = UIElement.GetState())
      catch { UIElement.SetState(Failed(save)); writef('0'); }
      pass { UIElement.SetState(save); writef('1'); }
      pass { passed = true; writef('2'); }
      body {
          ... lots of code ...
      }
      exit { writef('3'); }
 
      return passed;
 }
 


IMHO now it looks overcomplicated. You are explicitly declaring new scope
using body {} . This is for what whole idea was invented - to prevent it.

Using "catch" keyword is missleading. Keyword scope (expr.) works now as try
{ expr. } . And I have to say that I needed to read this code few times to
understand it. It looks for me as reinventing try { } catch { } finally {}
way of handling exceptions. Sorry, but I don't like it.

Feb 26 2006

↑ ↓ ← → James Dunne <james.jdunne gmail.com> writes:

Dawid Ciężarkiewicz wrote:
 James Dunne wrote:
 
I don't like the words 'success' and 'failure' used all over the place.


 
 Yes. I have to agree they are little missused. Changing them to "pass" as
 success, "fail"/"catch" as "failure" and "default" as exit is good idea.
 


Yeah, after posting I realized this was the best idea out of my post. 
Really, there's no *nice* way of fixing the syntax problem.  You have a 
fixed statement keyword - nobody will like what you name it; or you have 
the curly-brace blocks nesting - which looks busy.

 
void LongFunction()
{
     scope (State save = UIElement.GetState())
     catch {
         UIElement.SetState(Failed(save));
     }
     pass {
         UIElement.SetState(save);
     }
     body {
         ... lots of code ...
     }
}

This way, it looks like a function contract, except it applies to any
scope.  The catch block is reused but only for purposes of noting that
there was an exception caught.  The pass block is quite simply the
'else' to the catch block, and should happen only if no exceptions were
caught.  Furthermore, there could be a general 'exit' block.

One could add as many of these blocks as necessary, and the compiler
will guarantee to call them in order of definition, much like the
original solution but not requiring one to think backwards.

bool LongFunction()
{
     bool  passed = false;

     scope (State save = UIElement.GetState())
     catch { UIElement.SetState(Failed(save)); writef('0'); }
     pass { UIElement.SetState(save); writef('1'); }
     pass { passed = true; writef('2'); }
     body {
         ... lots of code ...
     }
     exit { writef('3'); }

     return passed;
}


 
 IMHO now it looks overcomplicated. You are explicitly declaring new scope
 using body {} . This is for what whole idea was invented - to prevent it.
 
 Using "catch" keyword is missleading. Keyword scope (expr.) works now as try
 { expr. } . And I have to say that I needed to read this code few times to
 understand it. It looks for me as reinventing try { } catch { } finally {}
 way of handling exceptions. Sorry, but I don't like it.


Reusing the catch keyword was not intended to be misleading, but instead 
to keep other whining about introducing new keywords.  Though, 
technically there's no reason for any keyword to actually be a reserved 
word in the first place... ;)

Yes, it does somewhat analogue try/catch/finally, but it is more 
explicit in its meaning.

Thanks for your opinion.

-- 
Regards,
James Dunne

Feb 26 2006

↑ ↓ ← → Kyle Furlong <kylefurlong gmail.com> writes:

James Dunne wrote:
 Kyle Furlong wrote:
 Dawid Ciężarkiewicz wrote:

 Dawid Ciężarkiewicz wrote:

 VERSION E:
 void LongFunction()
 {
 State save = UIElement.GetState();
 onscope {
         case success: UIElement.SetState(save);
     }
 onscope {
         case failure: UIElement.SetState(Failed(save));
     }
 ...lots of code...
 }



 Just came to my mind:

 This version is especially neat because it may be simplified to:
 void LongFunction()
 {
     State save = UIElement.GetState();
     onscope {
         case success: UIElement.SetState(save); break;
         case failure: UIElement.SetState(Failed(save));
     }
     ...lots of code...
 }



 I really like this idea, cons anyone?


 I don't like the words 'success' and 'failure' used all over the place. 
  The meaning of the function's success isn't based on only if no 
 exceptions were thrown.  Similarly, the function doesn't have to 'fail' 
 if an exception were thrown.
 
 I think they should be renamed to represent what they actually do.  That 
 is, 'no exception thrown'/'pass', 'exception thrown'/'catch', 'scope 
 exited'/'exit'.  Also, I think it would be more pleasing to the eye (and 
 the maintainer) if the effect of the scope guard were more obvious in 
 the code.  Something like:
 
 void LongFunction()
 {
     scope (State save = UIElement.GetState())
     catch {
         UIElement.SetState(Failed(save));
     }
     pass {
         UIElement.SetState(save);
     }
     body {
         ... lots of code ...
     }
 }
 
 This way, it looks like a function contract, except it applies to any 
 scope.  The catch block is reused but only for purposes of noting that 
 there was an exception caught.  The pass block is quite simply the 
 'else' to the catch block, and should happen only if no exceptions were 
 caught.  Furthermore, there could be a general 'exit' block.
 
 One could add as many of these blocks as necessary, and the compiler 
 will guarantee to call them in order of definition, much like the 
 original solution but not requiring one to think backwards.
 
 bool LongFunction()
 {
     bool  passed = false;
 
     scope (State save = UIElement.GetState())
     catch { UIElement.SetState(Failed(save)); writef('0'); }
     pass { UIElement.SetState(save); writef('1'); }
     pass { passed = true; writef('2'); }
     body {
         ... lots of code ...
     }
     exit { writef('3'); }
 
     return passed;
 }
 
 So, if an exception were thrown in '... lots of code ...', you'd see 
 '03' and the function would return false.  However, if no exception were 
 thrown you'd see '123' and the function would return true.  This 
 demonstrates the order of execution across multiple blocks.  In this 
 example, the order of the 'exit' block relative to the 'catch' and 
 'pass' blocks is important.
 
 Consequently, I don't think the order of the 'body' block should matter 
 at all, relative to the other blocks; and it should be fixed to only 
 allow one instance of it.  Then, it is a matter of personal/project 
 style where the 'body' block would fall.
 
 Thoughts on this?
 
 One last thought I had was to remove the parenthesized expression form 
 of scope (expr) ... and use another block name to represent the 
 initialization stage, just to be consistent.
 



for any scope:

in
{
}
out
{
}
failure
{
}
success
{
}
body
{
}

Pros: fits into and expands current language structures
Cons: still a bit verbose as compared to current syntax

Feb 26 2006

↑ ↓ ← → Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:

Kyle Furlong wrote:
 for any scope:
 
 in
 {
 }
 out
 {
 }
 failure
 {
 }
 success
 {
 }
 body
 {
 }
 
 Pros: fits into and expands current language structures
 Cons: still a bit verbose as compared to current syntax


I'm sorry to say but IMO this miss the whole point.

Current keywords: in, out, body are place-insensitive . They are just blocks
that may be moved relatively for themselves and this will not change
anything. The whole point in "scope guarding" is that expression you type
_registers_ some piece of code (to be called in some conditions) in place
where it appears.

You gain nothing with such syntax. If you want to deal with whole scope then
you can use finally and catch blocks.

Examples:

Current syntax:
void LongFunction()
{
    foo1();
    on_scope_failure clean_what_foo1_did();

    foo2();
    on_scope_failure clean_what_foo2_did();

    foo3();
    on_scope_failure clean_what_foo3_did();

    foo4();
}


What I understand from your proposal:
void LongFunction()
{
    foo1();
    failure {
        on_scope_failure clean_what_foo1_did();
    }
    body {

       foo2();

       failure {
           on_scope_failure clean_what_foo2_did();
       }
       body {
            foo3();
       
            failure {
               on_scope_failure clean_what_foo3_did();
            }
            body {
                foo4();
            }
       }
    }

}

If you think about:
void LongFunction()
{
    foo1();
    failure{
      clean_what_foo1_did();
    }

    foo2();
    failure {
     clean_what_foo2_did();
    }
    
    foo3();
    failure {
     on_scope_failure clean_what_foo3_did();
    }

    foo4();
}

Then concept is OK, but you can no longer say this "will fit and expand
current syntax", because it's used totally diffrent from  body {} in {} out
{} blocks.

Feb 26 2006

↑ ↓ ← → Kyle Furlong <kylefurlong gmail.com> writes:

Dawid Ciężarkiewicz wrote:
 Kyle Furlong wrote:
 for any scope:

 in
 {
 }
 out
 {
 }
 failure
 {
 }
 success
 {
 }
 body
 {
 }

 Pros: fits into and expands current language structures
 Cons: still a bit verbose as compared to current syntax


 I'm sorry to say but IMO this miss the whole point.
 
 Current keywords: in, out, body are place-insensitive . They are just blocks
 that may be moved relatively for themselves and this will not change
 anything. The whole point in "scope guarding" is that expression you type
 _registers_ some piece of code (to be called in some conditions) in place
 where it appears.
 
 You gain nothing with such syntax. If you want to deal with whole scope then
 you can use finally and catch blocks.
 
 Examples:
 
 Current syntax:
 void LongFunction()
 {
     foo1();
     on_scope_failure clean_what_foo1_did();
 
     foo2();
     on_scope_failure clean_what_foo2_did();
 
     foo3();
     on_scope_failure clean_what_foo3_did();
 
     foo4();
 }
 
 
 What I understand from your proposal:
 void LongFunction()
 {
     foo1();
     failure {
         on_scope_failure clean_what_foo1_did();
     }
     body {
 
        foo2();
 
        failure {
            on_scope_failure clean_what_foo2_did();
        }
        body {
             foo3();
        
             failure {
                on_scope_failure clean_what_foo3_did();
             }
             body {
                 foo4();
             }
        }
     }
 
 }
 
 If you think about:
 void LongFunction()
 {
     foo1();
     failure{
       clean_what_foo1_did();
     }
 
     foo2();
     failure {
      clean_what_foo2_did();
     }
     
     foo3();
     failure {
      on_scope_failure clean_what_foo3_did();
     }
 
     foo4();
 }
 
 Then concept is OK, but you can no longer say this "will fit and expand
 current syntax", because it's used totally diffrent from  body {} in {} out
 {} blocks.


That is definitely *NOT* what I was saying *AT ALL*. Obviously that is a
terrible syntax.

Here's what it would look like:

Current syntax:
void LongFunction()
{
     foo1();
     on_scope_failure clean_what_foo1_did();

     foo2();
     on_scope_failure clean_what_foo2_did();

     foo3();
     on_scope_failure clean_what_foo3_did();

     foo4();
}


What I understand from your proposal: (how it should have been)
void LongFunction()
failure
{
	clean_what_foo1_did();
	clean_what_foo2_did();
	clean_what_foo3_did();
	clean_what_foo4_did();
}
body
{
	foo1();
	foo2();
	foo3();
	foo4();
}

I think you missed the point that each function call does not introduce a new
scope. Now, its true that if you wanted the 
operations foox() to each be in its own scope, then it would look like this:

void LongFunction()
{
	failure
	{
		clean_what_foo1_did();
	}
	body
	{
		foo1();
	}
	failure
	{
		clean_what_foo2_did();
	}
	body
	{
		foo2();
	}
	failure
	{
		clean_what_foo3_did();
	}
	body
	{
		foo3();
	}
	failure
	{
		clean_what_foo4_did();
	}
	body
	{
		foo4();
	}
}

Feb 26 2006

↑ ↓ ← → Kyle Furlong <kylefurlong gmail.com> writes:

Kyle Furlong wrote:
 Dawid Ciężarkiewicz wrote:
 Kyle Furlong wrote:
 for any scope:

 in
 {
 }
 out
 {
 }
 failure
 {
 }
 success
 {
 }
 body
 {
 }

 Pros: fits into and expands current language structures
 Cons: still a bit verbose as compared to current syntax


 I'm sorry to say but IMO this miss the whole point.

 Current keywords: in, out, body are place-insensitive . They are just 
 blocks
 that may be moved relatively for themselves and this will not change
 anything. The whole point in "scope guarding" is that expression you type
 _registers_ some piece of code (to be called in some conditions) in place
 where it appears.

 You gain nothing with such syntax. If you want to deal with whole 
 scope then
 you can use finally and catch blocks.

 Examples:

 Current syntax:
 void LongFunction()
 {
     foo1();
     on_scope_failure clean_what_foo1_did();

     foo2();
     on_scope_failure clean_what_foo2_did();

     foo3();
     on_scope_failure clean_what_foo3_did();

     foo4();
 }


 What I understand from your proposal:
 void LongFunction()
 {
     foo1();
     failure {
         on_scope_failure clean_what_foo1_did();
     }
     body {

        foo2();

        failure {
            on_scope_failure clean_what_foo2_did();
        }
        body {
             foo3();
                    failure {
                on_scope_failure clean_what_foo3_did();
             }
             body {
                 foo4();
             }
        }
     }

 }

 If you think about:
 void LongFunction()
 {
     foo1();
     failure{
       clean_what_foo1_did();
     }

     foo2();
     failure {
      clean_what_foo2_did();
     }
         foo3();
     failure {
      on_scope_failure clean_what_foo3_did();
     }

     foo4();
 }

 Then concept is OK, but you can no longer say this "will fit and expand
 current syntax", because it's used totally diffrent from  body {} in 
 {} out
 {} blocks.


 That is definitely *NOT* what I was saying *AT ALL*. Obviously that is a 
 terrible syntax.
 
 Here's what it would look like:
 
 Current syntax:
 void LongFunction()
 {
     foo1();
     on_scope_failure clean_what_foo1_did();
 
     foo2();
     on_scope_failure clean_what_foo2_did();
 
     foo3();
     on_scope_failure clean_what_foo3_did();
 
     foo4();
 }
 
 
 What I understand from your proposal: (how it should have been)
 void LongFunction()
 failure
 {
     clean_what_foo1_did();
     clean_what_foo2_did();
     clean_what_foo3_did();
     clean_what_foo4_did();
 }
 body
 {
     foo1();
     foo2();
     foo3();
     foo4();
 }
 
 I think you missed the point that each function call does not introduce 
 a new scope. Now, its true that if you wanted the operations foox() to 
 each be in its own scope, then it would look like this:
 
 void LongFunction()
 {
     failure
     {
         clean_what_foo1_did();
     }
     body
     {
         foo1();
     }
     failure
     {
         clean_what_foo2_did();
     }
     body
     {
         foo2();
     }
     failure
     {
         clean_what_foo3_did();
     }
     body
     {
         foo3();
     }
     failure
     {
         clean_what_foo4_did();
     }
     body
     {
         foo4();
     }
 }


David has brought some things to my attention on IRC that invalidate this
syntax, sorry for the clutter.

Feb 26 2006

↑ ↓ ← → "Regan Heath" <regan netwin.co.nz> writes:

On Sun, 26 Feb 2006 12:20:58 -0800, Kyle Furlong <kylefurlong gmail.com>  
wrote:
 What I understand from your proposal: (how it should have been)
 void LongFunction()
 failure
 {
 	clean_what_foo1_did();
 	clean_what_foo2_did();
 	clean_what_foo3_did();
 	clean_what_foo4_did();
 }
 body
 {
 	foo1();
 	foo2();
 	foo3();
 	foo4();
 }


In the above:
  - is clean_what_foo1_did only called if foo1() has returned successfully  
and foo2,foo3,or foo4 failed?
  - is clean_what_foo2_did only called if foo2() has returned successfully  
and foo3,or foo4 failed?
  - is clean_what_foo3_did only called if foo3() has returned successfully  
and foo4 failed?

(there is actually no point to clean_what_foo4_did)

Because, this is an important part of the scope guard feature, each  
on_scope_failure statement registers something which is then called on  
failure of the scope in which it is registered. The order in which they  
are registered WRT the other code is important.

Regan

Feb 26 2006

↑ ↓ ← → John Reimer <terminal.node gmail.com> writes:

Dawid Ciężarkiewicz wrote:
 Walter Bright wrote:
 
 Scope guards are a novel feature no other language has. They're based on
 Andrei Alexandrescu's scope guard macros, which have led to considerable
 interest in the idea. Check out the article
 www.digitalmars.com/d/exception-safe.html


 Concept is really promising. Syntax ... well ... :D
 


<snip>

 
 VERSION B:
 void LongFunction()
 {
     State save = UIElement.GetState();
     scope (success) {
         UIElement.SetState(save);
     }
     scope (failure) {
         UIElement.SetState(Failed(save));
     }
     ...lots of code...
 }
 


<snip>


I like something similar to the "scope" keywords. That looks quite 
promising.

VERSION B +1

-JJR

Feb 26 2006

↑ ↓ ← → Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:

Dawid Ciężarkiewicz wrote:
 What do you think? Maybe later we'll come with better ideas.


VERSION F:
void LongFunction()
{
    State save = UIElement.GetState();
    register (scopepass) UIElement.SetState(save);
    register (scopefail) UIElement.SetState(Failed(save));
    ...lots of code...
}


VERSION G:
void LongFunction()
{
    State save = UIElement.GetState();
    register (scope) {
        case pass: UIElement.SetState(save); break;
        case fail: UIElement.SetState(Failed(save));
    }
    ...lots of code...
}

VERSION H:
void LongFunction()
{
    State save = UIElement.GetState();
    register {
        case scopepass: UIElement.SetState(save); break;
        case scopefail: UIElement.SetState(Failed(save));
    }
    ...lots of code...
}


P.S.
If I get more ideas I will throw them all (with those already posted) in one
new thread.

Feb 26 2006

↑ ↓ ← → Cris <central_p hotmail.com> writes:

Why do you need "case" at all?

Dawid Ciężarkiewicz wrote:
 Dawid Ciężarkiewicz wrote:
 What do you think? Maybe later we'll come with better ideas.


 VERSION F:
 void LongFunction()
 {
     State save = UIElement.GetState();
     register (scopepass) UIElement.SetState(save);
     register (scopefail) UIElement.SetState(Failed(save));
     ...lots of code...
 }
 
 
 VERSION G:
 void LongFunction()
 {
     State save = UIElement.GetState();
     register (scope) {
         case pass: UIElement.SetState(save); break;
         case fail: UIElement.SetState(Failed(save));
     }
     ...lots of code...
 }
 
 VERSION H:
 void LongFunction()
 {
     State save = UIElement.GetState();
     register {
         case scopepass: UIElement.SetState(save); break;
         case scopefail: UIElement.SetState(Failed(save));
     }
     ...lots of code...
 }
 
 
 P.S.
 If I get more ideas I will throw them all (with those already posted) in one
 new thread.

Feb 26 2006

↑ ↓ ← → Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:

Cris wrote:
 Why do you need "case" at all?


Good point. Intention was to make it similar to switch (smth.) block.

void LongFunction()
{
    State save = UIElement.GetState();
    register (scope) {
        pass: UIElement.SetState(save); break;
        fail: UIElement.SetState(Failed(save));
    }
    ...lots of code...
}

This looks better. I think about "(scope)" part. It's redundant _but_ very
informative and leaves open doors for expanding.

Currently I like this syntax best. IMO it naturally fits, "register" keyword
is old (but rarely used) old C-keyword and it realy means: "register this
piece of code to be called when something with scope happens".

Feb 26 2006

↑ ↓ ← → Cris <central_p hotmail.com> writes:

Now you have just to persuade Walter Bright or to write your own 
compiler/language :)

Dawid Ciężarkiewicz wrote:
 Dawid Ciężarkiewicz wrote:
 What do you think? Maybe later we'll come with better ideas.


 VERSION I: (yeah, I know ...)
 
 h3r3tic on #D channel said that VERSION H is too long and too switch-like.
 
 This is hybrid of two concepts - verbose and informative "register" keyword
 and short usage without switch-like syntax.
 
 void LongFunction()
 {
     State save = UIElement.GetState();
     register (scopepass) UIElement.SetState(save);
     register (scopefail) UIElement.SetState(Failed(save));
     ...lots of code...
 }

Feb 27 2006

↑ ↓ ← → John Reimer <John_member pathlink.com> writes:

In article <dtueau$pdo$1 digitaldaemon.com>, Cris says...
Now you have just to persuade Walter Bright or to write your own 
compiler/language :)

Dawid Ciężarkiewicz wrote:
 Dawid Ciężarkiewicz wrote:
 What do you think? Maybe later we'll come with better ideas.


 VERSION I: (yeah, I know ...)
 
 h3r3tic on #D channel said that VERSION H is too long and too switch-like.
 
 This is hybrid of two concepts - verbose and informative "register" keyword
 and short usage without switch-like syntax.
 
 void LongFunction()
 {
     State save = UIElement.GetState();
     register (scopepass) UIElement.SetState(save);
     register (scopefail) UIElement.SetState(Failed(save));
     ...lots of code...
 }
 





Hmm... we have "static if";  why not adopt a "scope if"?

Here's a sample using Walter's Mailer example from
http://www.digitalmars.com/d/exception-safe.html:

# class Mailer
# {
#     void Send( Message msg )
#     {
#          {
#              char[] origTitle = msg.Title();
#              
#              scope if (exit)
#                  msg.SetTitle( origTitle );
#              
#              msg.SetTitle("[Sending] " ~ origTitle);
#	       Copy(msg, "Sent");
#          }
#	   scope if(success) 
#              SetTitle(msg.ID(), "Sent", msg.Title);
#          scope if (failure)
#             Remove(msg.ID(), "Sent");
#          SmtpSend(msg);    // do the least reliable part last
#      }
# }

Simple, clear, and parallel to other D constructs, no?  We've certainly come to
enjoy the "static if" syntax.

-JJR

Feb 27 2006

↑ ↓ ← → h3 <h3 foo.bar> writes:

John Reimer wrote:
  > Hmm... we have "static if";  why not adopt a "scope if"?
 
 Here's a sample using Walter's Mailer example from
 http://www.digitalmars.com/d/exception-safe.html:
 
 # class Mailer
 # {
 #     void Send( Message msg )
 #     {
 #          {
 #              char[] origTitle = msg.Title();
 #              
 #              scope if (exit)
 #                  msg.SetTitle( origTitle );
 #              
 #              msg.SetTitle("[Sending] " ~ origTitle);
 #	       Copy(msg, "Sent");
 #          }
 #	   scope if(success) 
 #              SetTitle(msg.ID(), "Sent", msg.Title);
 #          scope if (failure)
 #             Remove(msg.ID(), "Sent");
 #          SmtpSend(msg);    // do the least reliable part last
 #      }
 # }
 
 Simple, clear, and parallel to other D constructs, no?  We've certainly come to
 enjoy the "static if" syntax.


Looks the best so far, but it implies making 'scope', 'success' and 
'failure' keywords. Not that I recall ever using them as identifiers...

Feb 27 2006

↑ ↓ ← → Charles <noone nowhere.com> writes:

I don't see how this is marginally better than try - catch - finnaly. 
Thanks to garbage collection , exception safety is dramatically less 
complicated in D then in C++ ( in fact other than the mutex lock -- can 
anyone think of examples for exception safety in D ? ).  I think the 
problem here is exceptions, not exception safety -- and I think that 
point is illustrated with all the many work arounds for 'exception safety'.

I love that D is "thinking outside the box" , but I have to vote against 
this one.  Instead of improving exception safety, we should be improving 
exceptions.

Charlie


Walter Bright wrote:
 Scope guards are a novel feature no other language has. They're based on 
 Andrei Alexandrescu's scope guard macros, which have led to considerable 
 interest in the idea. Check out the article 
 www.digitalmars.com/d/exception-safe.html

Feb 26 2006

↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:

"Ben Hinkle" <bhinkle mathworks.com> wrote in message 
news:dtv8f5$1svn$1 digitaldaemon.com...
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:dtr2fg$2vqr$4 digitaldaemon.com...
 Scope guards are a novel feature no other language has. They're based on 
 Andrei Alexandrescu's scope guard macros, which have led to considerable 
 interest in the idea. Check out the article 
 www.digitalmars.com/d/exception-safe.html


 Note GCC has pretty much the same thing with the "cleanup" attribute 
 extension on variables: 
 http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Variable-Attributes.html


cleanup only corresponds with on_scope_exit, not the other two. It also only 
runs a function with a local variable as a parameter - i.e. it is the same 
thing as RAII. It doesn't allow arbitrary code to be executed, nor manage 
things like state of a class member, etc.

Feb 27 2006

↑ ↓ ← → "Chris Miller" <chris dprogramming.com> writes:

On Sat, 25 Feb 2006 21:06:36 -0500, Walter Bright  
<newshound digitalmars.com> wrote:

 Scope guards are a novel feature no other language has. They're based on
 Andrei Alexandrescu's scope guard macros, which have led to considerable
 interest in the idea. Check out the article
 www.digitalmars.com/d/exception-safe.html


This format looks good to me:

scope(exit)  foo();
scope(success)  bar();
scope(failure)  baz();

similar to extern(name), pragma(name), etc, requires one `scope` keyword,  
name in () doesn't need to be a keyword but is still treated special, and  
doesn't look bad.

Feb 27 2006

↑ ↓ ← → Lars Ivar Igesund <larsivar igesund.net> writes:

Chris Miller wrote:

 On Sat, 25 Feb 2006 21:06:36 -0500, Walter Bright
 <newshound digitalmars.com> wrote:
 
 Scope guards are a novel feature no other language has. They're based on
 Andrei Alexandrescu's scope guard macros, which have led to considerable
 interest in the idea. Check out the article
 www.digitalmars.com/d/exception-safe.html


 This format looks good to me:
 
 scope(exit)  foo();
 scope(success)  bar();
 scope(failure)  baz();
 
 similar to extern(name), pragma(name), etc, requires one `scope` keyword,
 name in () doesn't need to be a keyword but is still treated special, and
 doesn't look bad.


Me votes for this too.

Feb 27 2006

↑ ↓ ← → "Derek Parnell" <derek psych.ward> writes:

On Tue, 28 Feb 2006 04:40:56 +1100, Chris Miller <chris dprogramming.com>  
wrote:

 On Sat, 25 Feb 2006 21:06:36 -0500, Walter Bright  
 <newshound digitalmars.com> wrote:

 Scope guards are a novel feature no other language has. They're based on
 Andrei Alexandrescu's scope guard macros, which have led to considerable
 interest in the idea. Check out the article
 www.digitalmars.com/d/exception-safe.html


 This format looks good to me:

 scope(exit)  foo();
 scope(success)  bar();
 scope(failure)  baz();

 similar to extern(name), pragma(name), etc, requires one `scope`  
 keyword, name in () doesn't need to be a keyword but is still treated  
 special, and doesn't look bad.


Nice and consistent.

-- 
Derek Parnell
Melbourne, Australia

Feb 27 2006

digitalmars.D - DMD 0.148 - scope guard