February 26, 2006
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...
>> Then it would look like an ordinary label, wouldn't it ? That's a different thing.
> Are there labels in D?

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
February 27, 2006
This looks like a great new D feature. Curse you. It makes it all that much worse that I still have to do my day-job programming in C++. Why did you ever have to invent D anyway? Why couldn't you just let me go on thinking C++ was a good thing? I thought I was happy then. :-)



Seriously, I read the Alexandrescu's article and downloaded the C++ Scopeguard code. I may end up using it. It's not as nice as D scopeguards though because you need to remember to call Dismiss at the end of functions. Plus, you probably want to avoid returning successfully in the middle of functions.



Jim




February 27, 2006
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 { ... }
February 27, 2006
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...
> }
> 
February 27, 2006
"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 :-(


February 27, 2006
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


February 27, 2006
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...
February 27, 2006
"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.


February 27, 2006
> Now we just need something sensible for on_scope_success and we're done ; )

"leave" seems like a good enough word, but since on_scope_failure and on_scope_success are mutually exclusive, we could use ~catch, or !catch. Pretty ugly too, but no new keywords.

on_scope_exit => finally
on_scope_failure => catch
on_scope_success => ~catch


February 27, 2006
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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Top | Discussion index | About this forum | D home