DMD 0.148 - scope guard

[James Dunne]

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