www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - request switch statement with common block

reply "JS" <js.mdnq gmail.com> writes:
switch (cond)
     common: always executed code here
     case A : etc...
     ....
}

instead of

if (cond) { always executed code here  }
switch (cond)
     case A : etc...
     ....
}

which requires modification of the condition twice when necessary
Aug 03 2013
next sibling parent "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
On Saturday, 3 August 2013 at 14:38:48 UTC, JS wrote:
 switch (cond)
     common: always executed code here
     case A : etc...
     ....
 }

 instead of

 if (cond) { always executed code here  }
 switch (cond)
     case A : etc...
     ....
 }

 which requires modification of the condition twice when 
 necessary
Can you give a real-world example, I'm not sure what's requested here?
Aug 03 2013
prev sibling next sibling parent "MattCodr" <mattcoder hotmail.com> writes:
On Saturday, 3 August 2013 at 14:38:48 UTC, JS wrote:
 switch (cond)
     common: always executed code here
     case A : etc...
     ....
 }

 instead of

 if (cond) { always executed code here  }
 switch (cond)
     case A : etc...
     ....
 }

 which requires modification of the condition twice when 
 necessary
Why don't you just: switch(cond) { default: // YOUR COMMON HERE case A: ... break; ... }
Aug 03 2013
prev sibling next sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 03.08.2013 16:38, schrieb JS:
 switch (cond)
       common: always executed code here
       case A : etc...
       ....
 }

 instead of

 if (cond) { always executed code here  }
 switch (cond)
       case A : etc...
       ....
 }

 which requires modification of the condition twice when necessary
switch does get an value not an condition in its scope (the cases are the evaluators) what is the sense of common in this switch example? switch(my_enum) { common: printf("common"); case A: printf("A"); break; case B: printf("B"); break; } why not write it like... printf("common"); switch(my_enum) { case A: printf("A"); break; case B: printf("B"); break; } cases are equal-to-value evaluators - so what is the evaluation of "common"? i don't get it, and speaking about fall-through principle is common always fired on start, on end or what?
Aug 03 2013
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 8/3/13 11:38 AM, JS wrote:
 switch (cond)
      common: always executed code here
      case A : etc...
      ....
 }

 instead of

 if (cond) { always executed code here  }
 switch (cond)
      case A : etc...
      ....
 }

 which requires modification of the condition twice when necessary
Do you mean this? switch(cond) { case A: common_code(); // something case B: common_code(); // something else } (common_code() must not be executed if it doesn't hit any switch case)
Aug 03 2013
parent reply "JS" <js.mdnq gmail.com> writes:
On Saturday, 3 August 2013 at 16:16:24 UTC, Ary Borenszweig wrote:
 On 8/3/13 11:38 AM, JS wrote:
 switch (cond)
     common: always executed code here
     case A : etc...
     ....
 }

 instead of

 if (cond) { always executed code here  }
 switch (cond)
     case A : etc...
     ....
 }

 which requires modification of the condition twice when 
 necessary
Do you mean this? switch(cond) { case A: common_code(); // something case B: common_code(); // something else } (common_code() must not be executed if it doesn't hit any switch case)
exactly
Aug 03 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/3/13 10:21 AM, JS wrote:
 On Saturday, 3 August 2013 at 16:16:24 UTC, Ary Borenszweig wrote:
 On 8/3/13 11:38 AM, JS wrote:
 switch (cond)
     common: always executed code here
     case A : etc...
     ....
 }

 instead of

 if (cond) { always executed code here  }
 switch (cond)
     case A : etc...
     ....
 }

 which requires modification of the condition twice when necessary
Do you mean this? switch(cond) { case A: common_code(); // something case B: common_code(); // something else } (common_code() must not be executed if it doesn't hit any switch case)
exactly
No because your initial rewrite suggested zero is special. But zero has no special meaning to the switch statement. Consider: switch (cond) { common: ... case 0: ... ... } Andrei
Aug 03 2013
parent reply "w0rp" <devw0rp gmail.com> writes:
I can see you saving a little bit of typing with this, but it's
not worth it.
Aug 03 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/3/2013 10:45 AM, w0rp wrote:
 I can see you saving a little bit of typing with this, but it's
 not worth it.
It would be a very unconventional syntactic form, and my experience with such things is it'll see very, very little use.
Aug 03 2013
parent reply "MattCoder" <mattcoder hotmail.com> writes:
On Saturday, 3 August 2013 at 18:04:03 UTC, Walter Bright wrote:
 On 8/3/2013 10:45 AM, w0rp wrote:
 I can see you saving a little bit of typing with this, but it's
 not worth it.
It would be a very unconventional syntactic form, and my experience with such things is it'll see very, very little use.
I would like to use this topic and ask if it would be possible to extend a feature of D language like in this case related by the author. Imagine that a user want to put a trigger when "switch statement" match some option, wouldn't be nice if D could do something like this: switch(x){ onBeforeMatch = callFoo(); case n1: ... case n2: ... } Where onBeforeMatch could be onAfterMatch. Matheus.
Aug 03 2013
parent reply "JS" <js.mdnq gmail.com> writes:
On Saturday, 3 August 2013 at 18:51:24 UTC, MattCoder wrote:
 On Saturday, 3 August 2013 at 18:04:03 UTC, Walter Bright wrote:
 On 8/3/2013 10:45 AM, w0rp wrote:
 I can see you saving a little bit of typing with this, but 
 it's
 not worth it.
It would be a very unconventional syntactic form, and my experience with such things is it'll see very, very little use.
I would like to use this topic and ask if it would be possible to extend a feature of D language like in this case related by the author. Imagine that a user want to put a trigger when "switch statement" match some option, wouldn't be nice if D could do something like this: switch(x){ onBeforeMatch = callFoo(); case n1: ... case n2: ... } Where onBeforeMatch could be onAfterMatch. Matheus.
You can accomplish the exact same and more with my suggestion. switch (x) { common: callFooBefore(); case n1: break; case n2: break; default: break; common: callFooAfter(); } else { } This should be the standard template for switch statements... why we must not progress out of the 80's is beyond me... What I really don't get it is why people think that just because they won't use such a feature then it must be useless to everyone else.
Aug 03 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/3/2013 12:00 PM, JS wrote:
 What I really don't get it is why people think that just because they won't use
 such a feature then it must be useless to everyone else.
You could provide supporting evidence by examining every use of switch in the dmd, phobos, and druntime source code, and see what percentage of those would benefit from your proposal. Consider, for example, the scope guard statement in D. It is extremely useful - but it is an unusual form (doesn't exist in other languages) and programmers just don't think in those terms. Andrei & I constantly have to work at 'selling' the benefits of it. It still hasn't really caught on.
Aug 03 2013
next sibling parent reply "JS" <js.mdnq gmail.com> writes:
On Saturday, 3 August 2013 at 19:22:53 UTC, Walter Bright wrote:
 On 8/3/2013 12:00 PM, JS wrote:
 What I really don't get it is why people think that just 
 because they won't use
 such a feature then it must be useless to everyone else.
You could provide supporting evidence by examining every use of switch in the dmd, phobos, and druntime source code, and see what percentage of those would benefit from your proposal.
This is illogical. The code wasn't written with such a semantic in mind so it would require me to rewrite the library to see how useful it truly is. The semantic should stand on it's own. Either it extends some basic functionality in a good way or it doesn't. i.e., Does it add value? If it does, then it should be implemented assuming the implementation costs and maintenance is not high. In this case the implementation costs and maintenance is near constant(since it is an orthogonal semantic not impacting any other aspect in the compiler but the switch statement itself). In fact, if the D compiler had some ability to easily implement transformations then one could simply rewrite the switch statement into what it represents. Such transformations depend only on the local context(what you are immediately transforming) and simply rewrite the code into other code. e.g., compiler see's switch (cond) { <common>: <common_body1> <body_end_statement>; case <symbol> : <case body> [break or return or fallthrough] ... <default> : <default_body> [break or return or fallthrough] <common>: <common_body2> <body_end_statement>; } else <else_body> AND rewrites it to if (cond) { <common_body1> } switch (cond) { case <symbol> : <case body> [break or return or fallthrough] ... <default> : <default_body> [break or return or fallthrough] } if (cond) { <common_body2> } if (!cond) { <else_body> } The second is already valid D. The first is a "short hand" which is less error prone and less verbose. Since the transformation is rather trivial and, in a sense, "linear", it is very low impact to the maintenance and implementation of the compiler. What it offers? Nothing to those that don't use it... everything to those that do.
 Consider, for example, the scope guard statement in D. It is 
 extremely useful - but it is an unusual form (doesn't exist in 
 other languages) and programmers just don't think in those 
 terms. Andrei & I constantly have to work at 'selling' the 
 benefits of it. It still hasn't really caught on.
And what I'm asking for is similar to scope guards for switch statements. You see how difficult is for me to "sell" it. But you can't design a language for the lowest common denominator. The best language available is the one that can do it all for everyone. With such a language everything else will follow. Having features that no one will use is not necessary bad... at some point chances are someone will want that feature and use it. For example, suppose what I am suggesting has zero cost to implement and maintain... Would you allow it in D? If not, why not? What are the drawbacks to having it? Is it error prone? Completely useless(Obviously not, because at least 2 people would find it useful)? etc...
Aug 03 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/3/2013 1:06 PM, JS wrote:
 On Saturday, 3 August 2013 at 19:22:53 UTC, Walter Bright wrote:
 On 8/3/2013 12:00 PM, JS wrote:
 What I really don't get it is why people think that just because they won't use
 such a feature then it must be useless to everyone else.
You could provide supporting evidence by examining every use of switch in the dmd, phobos, and druntime source code, and see what percentage of those would benefit from your proposal.
This is illogical. The code wasn't written with such a semantic in mind so it would require me to rewrite the library to see how useful it truly is.
There are two kinds of semantic language improvements: 1. one that is transformative to programming style, i.e. you'd write your program in a fundamentally different way, like OOP. 2. one that is automating an existing pattern, which is finding a recurring pattern in code and providing syntactic sugar for it. The foreach loop is in this category. Your proposal looks to me like (2), in fact, you wrote:
 Since the transformation is rather trivial
which supports that categorization. So, to make automating an existing pattern worthwhile, there ought to be a significant percentage of code exhibiting that existing pattern. For example, bearopile listed: enum mysize(T) = T.sizeof; which does automate a commonly recurring pattern.
 You see how difficult is for me to "sell" it.
Yes, and it should be difficult to sell a new language feature.
 For example, suppose what I am suggesting has zero cost to implement and
 maintain...

 Would you allow it in D?
There's no such thing - and certainly your proposal is not. Any syntactic change requires an ongoing cost in: 1. implementation 2. maintenance 3. testing 4. documentation 5. users have to learn it 6. books and tutorials about D have to discuss it Repeat steps 1..6 for every tool that deals with D source code. Therefore, there needs to be an advantage to it that outweigh all of that. It's a high bar. This is true for every language out there, and if you invent your own language, you'll quickly start applying that criteria as well.
Aug 03 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Regarding the feature proposed here, I think the extra complexity 
added doesn't pay enough back.


Walter Bright:

 You could provide supporting evidence by examining every use of 
 switch in the dmd, phobos, and druntime source code, and see 
 what percentage of those would benefit from your proposal.
Has someone done that regarding the last feature added to D, I mean the support for this syntax: enum mysize(T) = T.sizeof; template Pair(T) = Tuple(T, T); Bye, bearophile
Aug 03 2013
next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Saturday, 3 August 2013 at 20:38:37 UTC, bearophile wrote:
 Regarding the feature proposed here, I think the extra 
 complexity added doesn't pay enough back.


 Walter Bright:

 You could provide supporting evidence by examining every use 
 of switch in the dmd, phobos, and druntime source code, and 
 see what percentage of those would benefit from your proposal.
Has someone done that regarding the last feature added to D, I mean the support for this syntax: enum mysize(T) = T.sizeof; template Pair(T) = Tuple(T, T); Bye, bearophile
You pique my interest. What is this? Looks like template shorthand? I didn't find nything about it in docs. Could you share some links about this?
Aug 04 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 4 August 2013 at 15:32:17 UTC, monarch_dodra wrote:
 You pique my interest. What is this? Looks like template 
 shorthand? I didn't find nything about it in docs. Could you 
 share some links about this?
http://wiki.dlang.org/DIP42
Aug 04 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Sunday, 4 August 2013 at 15:38:01 UTC, Dicebot wrote:
 On Sunday, 4 August 2013 at 15:32:17 UTC, monarch_dodra wrote:
 You pique my interest. What is this? Looks like template 
 shorthand? I didn't find nything about it in docs. Could you 
 share some links about this?
http://wiki.dlang.org/DIP42
Awesome. I'll have to introduce std.traits to this new syntax.
Aug 04 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
monarch_dodra:

 Awesome. I'll have to introduce std.traits to this new syntax.
That DIP is not updated to what was actually implemented by Kenji. There is support for both enum and alias. But after a good look at my code base I have not found many places where the new syntax is useful. In my opinion it's handy, but it's not a large win. And I still haven't seen any kind of such statistics done on Phobos before the implementation of this feature pair. People have asked for a more general syntax, useful in more templates, but I have not seen a serious answer that explains why DIP42 is a good idea, while the other more general proposal (of a Self or something to be used in templates to make them more DRY) is is worse. Bye, bearophile
Aug 04 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/4/2013 11:30 AM, bearophile wrote:
 monarch_dodra:

 Awesome. I'll have to introduce std.traits to this new syntax.
That DIP is not updated to what was actually implemented by Kenji. There is support for both enum and alias. But after a good look at my code base I have not found many places where the new syntax is useful. In my opinion it's handy, but it's not a large win. And I still haven't seen any kind of such statistics done on Phobos before the implementation of this feature pair. People have asked for a more general syntax, useful in more templates, but I have not seen a serious answer that explains why DIP42 is a good idea, while the other more general proposal (of a Self or something to be used in templates to make them more DRY) is is worse.
I haven't collected statistics, but I see a repeated pattern in Phobos that is addressed by DIP42. It is also consistent with the other eponymous template shortcuts that enjoy wide usage.
Aug 04 2013
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 08/03/2013 01:38 PM, bearophile wrote:

 enum mysize(T) = T.sizeof;
That works...
 template Pair(T) = Tuple(T, T);
Instead, the following works (alias and !): alias Pair(T) = Tuple!(T, T); Is my change right? Ali
Aug 04 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Ali Çehreli:

 template Pair(T) = Tuple(T, T);
Instead, the following works (alias and !): alias Pair(T) = Tuple!(T, T); Is my change right?
Your change is right, I didn't give enough attention on the code I wrote, sorry :-) Bye, bearophile
Aug 04 2013
prev sibling next sibling parent "Andre Artus" <andre.artus gmail.com> writes:
On Saturday, 3 August 2013 at 19:22:53 UTC, Walter Bright wrote:
 On 8/3/2013 12:00 PM, JS wrote:
 What I really don't get it is why people think that just 
 because they won't use
 such a feature then it must be useless to everyone else.
You could provide supporting evidence by examining every use of switch in the dmd, phobos, and druntime source code, and see what percentage of those would benefit from your proposal. Consider, for example, the scope guard statement in D. It is extremely useful - but it is an unusual form (doesn't exist in other languages) and programmers just don't think in those terms. Andrei & I constantly have to work at 'selling' the benefits of it. It still hasn't really caught on.
The scope guard statement is my all-time favourite feature in D. It's so much easier to reason about than several layers of try/catch/finally. A close second is the Contracts, especially as it can be applied to interfaces. a huge win for service oriented programming.
Aug 05 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Aug 03, 2013 at 12:22:53PM -0700, Walter Bright wrote:
 On 8/3/2013 12:00 PM, JS wrote:
What I really don't get it is why people think that just because they
won't use such a feature then it must be useless to everyone else.
You could provide supporting evidence by examining every use of switch in the dmd, phobos, and druntime source code, and see what percentage of those would benefit from your proposal. Consider, for example, the scope guard statement in D. It is extremely useful - but it is an unusual form (doesn't exist in other languages) and programmers just don't think in those terms. Andrei & I constantly have to work at 'selling' the benefits of it. It still hasn't really caught on.
At least it has caught on with me. :) After learning about scope guards in D, I've been plagued with persistent thoughts of "I wish I could use a scope guard here!" every time I work with C/C++ code. Ironically, though, D's superior design has pretty much eliminated the need for scope guards except in a few rare cases. :-P They used to be still useful for things like closing files at the end of the block, but struct dtors have pretty much eliminated that use case as well. But I'd venture to say that in code that uses manual memory management (like game engines), scope guards are a lifesaver. Maybe Manu can chime in here. :) T -- The best compiler is between your ears. -- Michael Abrash
Aug 03 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, August 03, 2013 12:35:22 H. S. Teoh wrote:
 On Sat, Aug 03, 2013 at 12:22:53PM -0700, Walter Bright wrote:
 On 8/3/2013 12:00 PM, JS wrote:
What I really don't get it is why people think that just because they
won't use such a feature then it must be useless to everyone else.
You could provide supporting evidence by examining every use of switch in the dmd, phobos, and druntime source code, and see what percentage of those would benefit from your proposal. Consider, for example, the scope guard statement in D. It is extremely useful - but it is an unusual form (doesn't exist in other languages) and programmers just don't think in those terms. Andrei & I constantly have to work at 'selling' the benefits of it. It still hasn't really caught on.
At least it has caught on with me. :) After learning about scope guards in D, I've been plagued with persistent thoughts of "I wish I could use a scope guard here!" every time I work with C/C++ code. Ironically, though, D's superior design has pretty much eliminated the need for scope guards except in a few rare cases. :-P They used to be still useful for things like closing files at the end of the block, but struct dtors have pretty much eliminated that use case as well.
I'm surprised that you'd miss scope in C++ and yet not use it in D. The only thing that's really missing from C++ that D has that you might use in place of scope is finally. C++ has RAII just like D does. There's a much bigger difference when comparing against languages which don't have RAII (such as Java In general, I think that it comes down to a question of whether RAII or scope(exit) is more appropriate, and RAII works better in common cases (such as closing files or releasing a mutex), wheras scope(exit) works better in cases which aren't common (since it doesn't make sense to create types just for those cases). RAII also makes more sense in cases where you essentially need a reference count before doing the action rather than just when exiting the scope (e.g. closing files is also a good example of that; a File struct is more flexible than using scope(exit) to close the file). I definitely use scope from time to time, but I don't know how frequently I use it in comparison to how often I should use it. I was actually using scope(success) more until someone pointed out that there's an efficiency hit with that as it was putting try-catch blocks in places where there wouldn't have been before (as opposed to scope(exit) or scope(failure) where you'd be using try-catch blocks if you weren't using scope). - Jonathan M Davis
Aug 03 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Aug 03, 2013 at 01:33:44PM -0700, Jonathan M Davis wrote:
 On Saturday, August 03, 2013 12:35:22 H. S. Teoh wrote:
 On Sat, Aug 03, 2013 at 12:22:53PM -0700, Walter Bright wrote:
[...]
 Consider, for example, the scope guard statement in D. It is
 extremely useful - but it is an unusual form (doesn't exist in
 other languages) and programmers just don't think in those terms.
 Andrei & I constantly have to work at 'selling' the benefits of
 it. It still hasn't really caught on.
At least it has caught on with me. :) After learning about scope guards in D, I've been plagued with persistent thoughts of "I wish I could use a scope guard here!" every time I work with C/C++ code. Ironically, though, D's superior design has pretty much eliminated the need for scope guards except in a few rare cases. :-P They used to be still useful for things like closing files at the end of the block, but struct dtors have pretty much eliminated that use case as well.
I'm surprised that you'd miss scope in C++ and yet not use it in D.
Well, I miss it more in C than C++, but C++'s manual memory management does make scope rather attractive. The same goes for D, actually, but that's largely alleviated due to the built-in GC.
 The only thing that's really missing from C++ that D has that you
 might use in place of scope is finally.
Truth be told, I think scope trumps finally because it localizes the cleanup statement to the initialization. Sprinkling related code across two different places is more fragile and bug-prone.
 C++ has RAII just like D does.  There's a much bigger difference when
 comparing against languages which don't have RAII (such as Java or

Yeah, I think I mostly had C in mind when I wrote what I did. :)
 In general, I think that it comes down to a question of whether RAII
 or scope(exit) is more appropriate, and RAII works better in common
 cases (such as closing files or releasing a mutex), wheras scope(exit)
 works better in cases which aren't common (since it doesn't make sense
 to create types just for those cases). RAII also makes more sense in
 cases where you essentially need a reference count before doing the
 action rather than just when exiting the scope (e.g. closing files is
 also a good example of that; a File struct is more flexible than using
 scope(exit) to close the file).
Yeah, with RAII, much of the use cases of scope is eliminated. I'm mainly working with C at my job right now, which is why I miss scope so much. C is just so tedious to use due to the amount of manual baby-sitting required to make things work properly. I still miss scope in C++ because of the lack of a GC, but otherwise, even C++ doesn't have that many use cases for scope left.
 I definitely use scope from time to time, but I don't know how
 frequently I use it in comparison to how often I should use it. I was
 actually using scope(success) more until someone pointed out that
 there's an efficiency hit with that as it was putting try-catch blocks
 in places where there wouldn't have been before (as opposed to
 scope(exit) or scope(failure) where you'd be using try-catch blocks if
 you weren't using scope).
[...] Hmm, I never thought of that. So that limits the use cases of scope guards even more. :-P T -- My program has no bugs! Only unintentional features...
Aug 03 2013
prev sibling parent reply "JS" <js.mdnq gmail.com> writes:
On Saturday, 3 August 2013 at 17:45:11 UTC, w0rp wrote:
 I can see you saving a little bit of typing with this, but it's
 not worth it.
Um, it can actually save a lot of type and errors. having two places to change is very error prone. if (cond) { } switch(cond) If the condition is complex and one forgets it is the same condition then only changing one block will cause bugs. It is not a hard feature to have AND it is worth it because it is a near zero complex compiler implementation. So, depending on how you define "not worth it", which I take "I'm too lazy to implement it", you could be correct.
Aug 03 2013
next sibling parent reply "Andre Artus" <andre.artus gmail.com> writes:
On Saturday, 3 August 2013 at 18:56:47 UTC, JS wrote:
 On Saturday, 3 August 2013 at 17:45:11 UTC, w0rp wrote:
 I can see you saving a little bit of typing with this, but it's
 not worth it.
Um, it can actually save a lot of type and errors. having two places to change is very error prone. if (cond) { } switch(cond) If the condition is complex and one forgets it is the same condition then only changing one block will cause bugs. It is not a hard feature to have AND it is worth it because it is a near zero complex compiler implementation. So, depending on how you define "not worth it", which I take "I'm too lazy to implement it", you could be correct.
If the implementation is so obviously trivial why don't you implement a proof of concept? The compiler is open source after all. People routinely underestimate the ripple effect that adding 'trivial' extensions to a language can have on a language.
Aug 03 2013
next sibling parent "Meta" <jared771 gmail.com> writes:
On Saturday, 3 August 2013 at 19:10:19 UTC, Andre Artus wrote:
 If the implementation is so obviously trivial why don't you 
 implement a proof of concept? The compiler is open source after 
 all.
This seems like something that would be fairly simple to implement using a mixin template, so you may not have to go as far as hacking the compiler.
Aug 03 2013
prev sibling parent reply "JS" <js.mdnq gmail.com> writes:
On Saturday, 3 August 2013 at 19:10:19 UTC, Andre Artus wrote:
 On Saturday, 3 August 2013 at 18:56:47 UTC, JS wrote:
 On Saturday, 3 August 2013 at 17:45:11 UTC, w0rp wrote:
 I can see you saving a little bit of typing with this, but 
 it's
 not worth it.
Um, it can actually save a lot of type and errors. having two places to change is very error prone. if (cond) { } switch(cond) If the condition is complex and one forgets it is the same condition then only changing one block will cause bugs. It is not a hard feature to have AND it is worth it because it is a near zero complex compiler implementation. So, depending on how you define "not worth it", which I take "I'm too lazy to implement it", you could be correct.
If the implementation is so obviously trivial why don't you implement a proof of concept? The compiler is open source after all.
because I have better things to do and there is an extreme likelihood it won't be accepted.
 People routinely underestimate the ripple effect that adding 
 'trivial' extensions to a language can have on a language.
Um, and people routinely don't think hard enough about the problem to realize the feature is an orthogonal semantic that has no bearing on anything but what it does. Why do I know this? Because the feature is short hand notation that can be directly implemented the long way. If the long way doesn't have problems, then the short way does not have any problems(except if your implementation is bad, but that's not the fault of the short way). I can write a preprocessor to do the things I need to do. I have done it before. The problem is it is hard to make such features robust without some grammatical context such as an ast.
Aug 03 2013
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Saturday, 3 August 2013 at 19:51:33 UTC, JS wrote:
 ...
I am afraid creating your own language may be your only possibility to get a language that shares your views on "proper" design. Because with each new topic it becomes more and more clear that D is unlikely to fit into that picture. Being useful for someone is _not_ enough to add a feature. It must be useful for a very large amount of cases and/or provide some advantage that can't be achieved in 3x-5x amount of code without it. Anything less than this does not pull its own weight.
Aug 03 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/3/2013 12:51 PM, JS wrote:
 On Saturday, 3 August 2013 at 19:10:19 UTC, Andre Artus wrote:
 If the implementation is so obviously trivial why don't you implement a proof
 of concept?
because I have better things to do
Implying that our time is of lesser value than yours does not help sell your ideas :-)
Aug 03 2013
parent reply "JS" <js.mdnq gmail.com> writes:
On Saturday, 3 August 2013 at 21:42:00 UTC, Walter Bright wrote:
 On 8/3/2013 12:51 PM, JS wrote:
 On Saturday, 3 August 2013 at 19:10:19 UTC, Andre Artus wrote:
 If the implementation is so obviously trivial why don't you 
 implement a proof
 of concept?
because I have better things to do
Implying that our time is of lesser value than yours does not help sell your ideas :-)
No, you guys have a vested interest in D and are the owners who make the final say so... All I can do is present an argument and watch it get shot down. The only real solution for me is to develop my own language and compilers... But I neither have the time nor the intelligence to do so(at least to do something worthwhile). But nonetheless, there are certain fundamental properties in language design. I believe that a compilers ONLY goal is to make life easier for the programmer. Hence "short form" is key to this when it does not obfuscate. I think using the criteria that only denies features that are useful to only a few programmers is very short sighted. The reason C++ is better than C is because of it's feature set. Stuff like i++(short form) is ONLY for convenience... yet every uses it! NOT because they used it before it exists(obviously) but because the language supported it and then people were able to see how useful it is(and some things take a long time. Basically "How the hell do you know if something is going to be useful to programmers if the language doesn't support it"? The answer? You don't! But you can get a good idea if what you are asking for is a generalization of something. If X is a generalization of Y and Y is used then chances are X will be used at some point when people are able to grasp what it does. For example, what I am proposing is analogous to class inheritance. You have a standard base class(the current switch statement) and a derived class(my extension of the switch). We can use the derived class anywhere we use the base class(we can use the standard switch statement even if we have the ability to use the extended version). Derivation is always good because it is backwards compatible(conceptually). My switch statement extension is fully backwards compatible with the original. Hence, in no way does it break current usage, so no one can get upset it broke their program. But it makes the language more robust, easier to understand in some cases(but not less in any), and is orthogonal to all other language features(so very little maintenance issues/unintended consequences).
Aug 03 2013
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Sunday, 4 August 2013 at 01:57:04 UTC, JS wrote:
 Stuff like i++(short form) is ONLY for convenience... yet every 
 uses it! NOT because they used it before it exists(obviously) 
 but because the language supported it and then people were able 
 to see how useful it is(and some things take a long time.
IIRC post/pre-increment/decrement syntax wasn't introduced in C for peoples convenience, it was there to allow naive compilers to use the then faster increment instructions.
Aug 04 2013
prev sibling parent "Andre Artus" <andre.artus gmail.com> writes:
 So, depending on how you define "not worth it", which I take 
 "I'm too lazy to implement it", you could be correct.
 YaAA:
 If the implementation is so obviously trivial why don't you 
 implement a proof of concept? The compiler is open source 
 after all.
 JS:
 because I have better things to do and there is an extreme 
 likelihood it won't be accepted.
So, you have better things to do, but other people are lazy if they do not implement something you need but they don't? It's a proof of concept, you offer it to other users (if you build it they will come, or not) who, if they find it as useful as you apparently do will lobby on your behalf.
 YaAA
 People routinely underestimate the ripple effect that adding 
 'trivial' extensions to a language can have on a language.
 JS
 Um, and people routinely don't think hard enough about the 
 problem to realize the feature is an orthogonal semantic that 
 has no bearing on anything but what it does.
It's not true that it has no bearing on anything else.
 JS
 Why do I know this?

 Because the feature is short hand notation that can be directly 
 implemented the long way. If the long way doesn't have 
 problems, then the short way does not have any problems(except 
 if your implementation is bad, but that's not the fault of the 
 short way).

 I can write a preprocessor to do the things I need to do. I 
 have done it before. The problem is it is hard to make such 
 features robust without some grammatical context such as an ast.
You have the source code for the compiler at your disposal. If this is as trivial to implement, and as useful to you, as you claim, then I do not see why you cannot knock something together to showcase the feature. Are you unwilling to do any work to see this feature implemented? If so, how can you impugn the work ethic of someone (by implying that they ate lazy), who has already donated their time and toil to you, if they follow suit? Language design is by necessity a conservative affair; it's easy for a language to die a death-by-a-thousand-features. See if you can find some real-world examples of where this pattern could be useful. At the very least you need to specify the construct in more detail addressing, for example, the following: - Does it only work on "final switch" or any switch? - How are non-integer expressions handled, if at all? - How does it interpret 'default'? - How does it deal with range gaps? - ...
Aug 03 2013
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Saturday, 3 August 2013 at 18:56:47 UTC, JS wrote:
 Um, it can actually save a lot of type and errors.

 having two places to change is very error prone.

 if (cond) { }
 switch(cond)
What is error-prone is evaluation of a complex condition twice assuming it will result in the same value. That's also a common error with C macros. You should save the value in a variable: auto cond = complexCond; if (cond) { } switch(cond)...
Aug 04 2013
parent reply "Andre Artus" <andre.artus gmail.com> writes:
On Sunday, 4 August 2013 at 10:14:50 UTC, Kagamin wrote:
 On Saturday, 3 August 2013 at 18:56:47 UTC, JS wrote:
 Um, it can actually save a lot of type and errors.

 having two places to change is very error prone.

 if (cond) { }
 switch(cond)
What is error-prone is evaluation of a complex condition twice assuming it will result in the same value. That's also a common error with C macros. You should save the value in a variable: auto cond = complexCond; if (cond) { } switch(cond)...
There is also a subtle, but in my opinion important, distinction between the expressions accepted by 'if' and 'switch'. With 'if' the expression must evaluate to boolean, whereas with 'switch' the expression evaluates to an integral or {w|d}char[] type. With a 'switch' the condition is completed in the 'case'. Taking an example from int number; string message; switch (number) { default: // valid: ends with 'throw' throw new Exception("unknown number"); case 3: message ~= "three "; break; case 4: message ~= "four "; continue; case 5: message ~= "five "; goto case; case 6: message ~= "six "; break; case 1: case 2: message = "one or two"; }
Aug 04 2013
parent reply "Andre Artus" <andre.artus gmail.com> writes:
On Sunday, 4 August 2013 at 15:57:32 UTC, Andre Artus wrote:
 On Sunday, 4 August 2013 at 10:14:50 UTC, Kagamin wrote:
 On Saturday, 3 August 2013 at 18:56:47 UTC, JS wrote:
 Um, it can actually save a lot of type and errors.

 having two places to change is very error prone.

 if (cond) { }
 switch(cond)
What is error-prone is evaluation of a complex condition twice assuming it will result in the same value. That's also a common error with C macros. You should save the value in a variable: auto cond = complexCond; if (cond) { } switch(cond)...
There is also a subtle, but in my opinion important, distinction between the expressions accepted by 'if' and 'switch'. With 'if' the expression must evaluate to boolean, whereas with 'switch' the expression evaluates to an integral or {w|d}char[] type. With a 'switch' the condition is completed in the 'case'.
Oops. I think I hit spacebar twice and the message was posted before I finished it. Taking an example from the D language reference,
 int number;
 string message;
 switch (number)
 {
 	default: // valid: ends with 'throw'
 	throw new Exception("unknown number");
 	case 3:
 		message ~= "three "; break;
 	case 4:
 		message ~= "four "; continue;
 	case 5:
 		message ~= "five "; goto case;
 	case 6:
 		message ~= "six "; break;
 	case 1:
 	case 2:
 		message = "one or two";
  }
With the inclusion of 'default' the condition covers the whole range of 'int'. The programmer may only want the pre and post code to be executed for every other case (1..6). switch (number) { default: // valid: ends with 'throw' throw new Exception("unknown number"); case 3: message ~= "three "; break; case 5: message ~= "five "; goto case; case 6: message ~= "six "; break; case 2: message = "one or two"; } Here the range is interrupted, but covered by 'default'. What does the compiler do here? Sorry I have to go make supper now, but I have a lot more to say on this.
Aug 04 2013
parent reply "MattCoder" <mattcoder hotmail.com> writes:
On Sunday, 4 August 2013 at 16:16:25 UTC, Andre Artus wrote:
 On Sunday, 4 August 2013 at 15:57:32 UTC, Andre Artus wrote:
 On Sunday, 4 August 2013 at 10:14:50 UTC, Kagamin wrote:
 On Saturday, 3 August 2013 at 18:56:47 UTC, JS wrote:
 Um, it can actually save a lot of type and errors.

 having two places to change is very error prone.

 if (cond) { }
 switch(cond)
What is error-prone is evaluation of a complex condition twice assuming it will result in the same value. That's also a common error with C macros. You should save the value in a variable: auto cond = complexCond; if (cond) { } switch(cond)...
There is also a subtle, but in my opinion important, distinction between the expressions accepted by 'if' and 'switch'. With 'if' the expression must evaluate to boolean, whereas with 'switch' the expression evaluates to an integral or {w|d}char[] type. With a 'switch' the condition is completed in the 'case'.
Oops. I think I hit spacebar twice and the message was posted before I finished it. Taking an example from the D language reference,
 int number;
 string message;
 switch (number)
 {
 	default: // valid: ends with 'throw'
 	throw new Exception("unknown number");
 	case 3:
 		message ~= "three "; break;
 	case 4:
 		message ~= "four "; continue;
 	case 5:
 		message ~= "five "; goto case;
 	case 6:
 		message ~= "six "; break;
 	case 1:
 	case 2:
 		message = "one or two";
 }
With the inclusion of 'default' the condition covers the whole range of 'int'. The programmer may only want the pre and post code to be executed for every other case (1..6).
Like I said, it would be nice if we could extend some D features without change the compiler source, maybe like macros in LISP. The switch statement should have an event handler like: onBeforeMatch or onAfterMatch to handle this. But for what I saw on this thread, this is only possible changing the compiler source. :/ Matheus.
Aug 04 2013
parent reply "Andre Artus" <andre.artus gmail.com> writes:
 Andre Artus:
 int number;
 string message;
 switch (number)
 {
 	default: // valid: ends with 'throw'
 		throw new Exception("unknown number");
 	case 3:
 		message ~= "three "; break;
 	case 4:
 		message ~= "four "; continue;
 	case 5:
 		message ~= "five "; goto case;
 	case 6:
 		message ~= "six "; break;
 	case 1:
 	case 2:
 		message = "one or two";
 }

 With the inclusion of 'default' the condition covers the whole 
 range of 'int'. The programmer may only want the pre  and post 
 code to be executed for every other case (1..6).
 MattCoder:
 Like I said, it would be nice if we could extend some D 
 features without change the compiler source, maybe like macros 
 in LISP.
It may not always be the case, but in my experience this often leads to write-only code. I'm pretty new to D, so I'm not quite up to speed with the metaprogramming abilities, but I'm under the impression that this is what mixin's are for.
 MattCoder:
 The switch statement should have an event handler like: 
 onBeforeMatch or onAfterMatch to handle this.

 But for what I saw on this thread, this is only possible 
 changing the compiler source. :/

 Matheus.
In order to produce the most sane (in my opinion) construct the code cannot be rewritten as JS suggested:
 JS:

 if (cond) { <common_body1> }
 switch (cond)
 {
     case <symbol> : <case body> [break or return or fallthrough]
     ...
     <default> : <default_body>  [break or return or fallthrough]
 }
 if (cond) { <common_body2> }
 if (!cond) { <else_body> }
As I mentioned before `switch` takes an expression that evaluates to integral or char[], the condition is completed in the `case`. The condition leading to the 'common' entry and exit code must replicate that of the complete switch statement. This begs the question about how to handle `default`. It would be difficult to correctly reason about the code without additional information. The only suggestion that leads to sane results in all (maybe?) cases is that made by Ary Borenszweig.
 Ary Borenszweig:

 switch(cond) {
   case A:
     common_code();
     // something
   case B:
     common_code();
     // something else
 }
I would think that the common code could be factored into a delegate) then passing the case specific code as a lambda. This private void UseAGoodNameDescribingCommonCode(Action action) { // Entry code action(); // Exit code } switch(expression) { case A: UseAGoodNameDescribingCommonCode(() => { // something }); break; case B: UseAGoodNameDescribingCommonCode(() => { // something }); break; default: // Something else } It's very clear where it's being applied, and where it is not. If the compiler was rewriting the following: switch(expression) { common_entry: // should not be order specific i.e. overloading 'common' // entry code break; common_exit: // exit code break; case A: // something break; case B: // something else break; default: // default something } It could produce something like this: switch(expression) { common_entry: // should not be order specific i.e. overloading 'common' // entry code goto pop_label(); common_exit: // exit code break; case A: // could set var or register used push/pop for clarity of intent push_label(A_prime); goto case common_entry; label A_prime: // something goto case common_exit; // break not needed here; case B: // rinse & repeat label B_prime: // rinse & repeat default: // default something } What to do with default needs to be disambiguated.
Aug 04 2013
next sibling parent reply "Andre Artus" <andre.artus gmail.com> writes:
On Monday, 5 August 2013 at 04:07:55 UTC, Andre Artus wrote:
 Andre Artus:
 int number;
 string message;
 switch (number)
 {
 	default: // valid: ends with 'throw'
 		throw new Exception("unknown number");
 	case 3:
 		message ~= "three "; break;
 	case 4:
 		message ~= "four "; continue;
 	case 5:
 		message ~= "five "; goto case;
 	case 6:
 		message ~= "six "; break;
 	case 1:
 	case 2:
 		message = "one or two";
 }

 With the inclusion of 'default' the condition covers the 
 whole range of 'int'. The programmer may only want the pre  
 and post code to be executed for every other case (1..6).
 MattCoder:
 Like I said, it would be nice if we could extend some D 
 features without change the compiler source, maybe like macros 
 in LISP.
It may not always be the case, but in my experience this often leads to write-only code. I'm pretty new to D, so I'm not quite up to speed with the metaprogramming abilities, but I'm under the impression that this is what mixin's are for.
 MattCoder:
 The switch statement should have an event handler like: 
 onBeforeMatch or onAfterMatch to handle this.

 But for what I saw on this thread, this is only possible 
 changing the compiler source. :/

 Matheus.
In order to produce the most sane (in my opinion) construct the code cannot be rewritten as JS suggested:
 JS:

 if (cond) { <common_body1> }
 switch (cond)
 {
    case <symbol> : <case body> [break or return or fallthrough]
    ...
    <default> : <default_body>  [break or return or fallthrough]
 }
 if (cond) { <common_body2> }
 if (!cond) { <else_body> }
As I mentioned before `switch` takes an expression that evaluates to integral or char[], the condition is completed in the `case`. The condition leading to the 'common' entry and exit code must replicate that of the complete switch statement. This begs the question about how to handle `default`. It would be difficult to correctly reason about the code without additional information. The only suggestion that leads to sane results in all (maybe?) cases is that made by Ary Borenszweig.
 Ary Borenszweig:

 switch(cond) {
  case A:
    common_code();
    // something
  case B:
    common_code();
    // something else
 }
I would think that the common code could be factored into a delegate) then passing the case specific code as a lambda. This private void UseAGoodNameDescribingCommonCode(Action action) { // Entry code action(); // Exit code } switch(expression) { case A: UseAGoodNameDescribingCommonCode(() => { // something }); break; case B: UseAGoodNameDescribingCommonCode(() => { // something }); break; default: // Something else } It's very clear where it's being applied, and where it is not. If the compiler was rewriting the following: switch(expression) { common_entry: // should not be order specific i.e. overloading 'common' // entry code break; common_exit: // exit code break; case A: // something break; case B: // something else break; default: // default something } It could produce something like this: switch(expression) { common_entry: // should not be order specific i.e. overloading 'common' // entry code goto pop_label(); common_exit: // exit code break; case A: // could set var or register used push/pop for clarity of intent push_label(A_prime); goto case common_entry; label A_prime: // something goto case common_exit; // break not needed here; case B: // rinse & repeat label B_prime: // rinse & repeat default: // default something } What to do with default needs to be disambiguated.
I should point out that 'common_entry' and 'common_exit' are not really cases, but labels as they are not explicitly tied to the input expression.
Aug 04 2013
parent reply "luminousone" <rd.hunt gmail.com> writes:
perhaps a more generic solution should be looked at, extend 
contracts to work with all scope blocks.

switch(somenumber)
in {
     ... before stuff ...
}
out {
     .... after stuff ...
}
body {
     case 1:
     in {
        ... etc ....
     }
     out {
        ... more etc ...
     }
     body {
        ...
     }
     case 2:
       // and so on
}

or perhaps

for( int i = 0 ; i < 10 ; i ++ )
in {
     assert( i == 0 );
}
out {
     assert( i == 9 );
}
body {
    ... stuff ...
}

if it is desired for a particular contract block to be called in 
release builds perhaps a attribute label to mark it as a runtime 
block or something similar.

foreach( i, k ; somerange )
 runtime in {
  ...
}
body {
}
Aug 04 2013
next sibling parent reply "Andre Artus" <andre.artus gmail.com> writes:
On Monday, 5 August 2013 at 06:28:12 UTC, luminousone wrote:
 perhaps a more generic solution should be looked at, extend 
 contracts to work with all scope blocks.

 switch(somenumber)
 in {
     ... before stuff ...
 }
 out {
     .... after stuff ...
 }
 body {
     case 1:
     in {
        ... etc ....
     }
     out {
        ... more etc ...
     }
     body {
        ...
     }
     case 2:
       // and so on
 }

 or perhaps

 for( int i = 0 ; i < 10 ; i ++ )
 in {
     assert( i == 0 );
 }
 out {
     assert( i == 9 );
 }
 body {
    ... stuff ...
 }

 if it is desired for a particular contract block to be called 
 in release builds perhaps a attribute label to mark it as a 
 runtime block or something similar.

 foreach( i, k ; somerange )
  runtime in {
  ...
 }
 body {
 }
Please do not take offense, but I do not see this as a good idea. Contracts have a very different function; not just in D, but every language that uses them. The idea is to support design-by-contract programming. Overloading the constructs for the purposes proposed here would, in my opinion, cause confusion and/or weaken the proper use of contract programming. The code in the contract conditions should never do anything more than what is necessary to specify the contract. It should not do explicit IO (other than implied by assert()), mutate state, or anything like that. At the bottom of this page you can find a reading list for more info. http://www.digitalmars.com/d/dbc.html Or for a general overview: http://en.wikipedia.org/wiki/Design_by_contract Walter, does the D compiler or any of it's companion tools do any static analysis on the contracts? Such as a void safety/null reference check?
Aug 05 2013
parent reply "ron" <rd.hunt gmail.com> writes:
On Monday, 5 August 2013 at 08:46:54 UTC, Andre Artus wrote:
 On Monday, 5 August 2013 at 06:28:12 UTC, luminousone wrote:
 perhaps a more generic solution should be looked at, extend 
 contracts to work with all scope blocks.

 switch(somenumber)
 in {
    ... before stuff ...
 }
 out {
    .... after stuff ...
 }
 body {
    case 1:
    in {
       ... etc ....
    }
    out {
       ... more etc ...
    }
    body {
       ...
    }
    case 2:
      // and so on
 }

 or perhaps

 for( int i = 0 ; i < 10 ; i ++ )
 in {
    assert( i == 0 );
 }
 out {
    assert( i == 9 );
 }
 body {
   ... stuff ...
 }

 if it is desired for a particular contract block to be called 
 in release builds perhaps a attribute label to mark it as a 
 runtime block or something similar.

 foreach( i, k ; somerange )
  runtime in {
 ...
 }
 body {
 }
Please do not take offense, but I do not see this as a good idea. Contracts have a very different function; not just in D, but every language that uses them. The idea is to support design-by-contract programming. Overloading the constructs for the purposes proposed here would, in my opinion, cause confusion and/or weaken the proper use of contract programming. The code in the contract conditions should never do anything more than what is necessary to specify the contract. It should not do explicit IO (other than implied by assert()), mutate state, or anything like that. At the bottom of this page you can find a reading list for more info. http://www.digitalmars.com/d/dbc.html Or for a general overview: http://en.wikipedia.org/wiki/Design_by_contract Walter, does the D compiler or any of it's companion tools do any static analysis on the contracts? Such as a void safety/null reference check?
None taken, =-p. I don't see how this is different from current contract usage, right now they apply to function scopes only. currently I believe you could get a similar effect via using an inner function. void a() { int i = 0; void b() in { assert( i == 0 ); } out { assert( i == 10 ); } body { for( ; i < 10 ; i ++ ) { ... do something ... } } b(); }
Aug 05 2013
next sibling parent reply "Borislav Kosharov" <bosak gmail.com> writes:
On Monday, 5 August 2013 at 19:58:21 UTC, ron wrote:
 On Monday, 5 August 2013 at 08:46:54 UTC, Andre Artus wrote:
 On Monday, 5 August 2013 at 06:28:12 UTC, luminousone wrote:
 perhaps a more generic solution should be looked at, extend 
 contracts to work with all scope blocks.

 switch(somenumber)
 in {
   ... before stuff ...
 }
 out {
   .... after stuff ...
 }
 body {
   case 1:
   in {
      ... etc ....
   }
   out {
      ... more etc ...
   }
   body {
      ...
   }
   case 2:
     // and so on
 }

 or perhaps

 for( int i = 0 ; i < 10 ; i ++ )
 in {
   assert( i == 0 );
 }
 out {
   assert( i == 9 );
 }
 body {
  ... stuff ...
 }

 if it is desired for a particular contract block to be called 
 in release builds perhaps a attribute label to mark it as a 
 runtime block or something similar.

 foreach( i, k ; somerange )
  runtime in {
 ...
 }
 body {
 }
Please do not take offense, but I do not see this as a good idea. Contracts have a very different function; not just in D, but every language that uses them. The idea is to support design-by-contract programming. Overloading the constructs for the purposes proposed here would, in my opinion, cause confusion and/or weaken the proper use of contract programming. The code in the contract conditions should never do anything more than what is necessary to specify the contract. It should not do explicit IO (other than implied by assert()), mutate state, or anything like that. At the bottom of this page you can find a reading list for more info. http://www.digitalmars.com/d/dbc.html Or for a general overview: http://en.wikipedia.org/wiki/Design_by_contract Walter, does the D compiler or any of it's companion tools do any static analysis on the contracts? Such as a void safety/null reference check?
None taken, =-p. I don't see how this is different from current contract usage, right now they apply to function scopes only. currently I believe you could get a similar effect via using an inner function. void a() { int i = 0; void b() in { assert( i == 0 ); } out { assert( i == 10 ); } body { for( ; i < 10 ; i ++ ) { ... do something ... } } b(); }
Speaking of contracts, and reading the docs I see: "Pre and Post Contracts The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has..." So are contracts possible outside function declarations? For example just scopes or random places in code.
Aug 05 2013
next sibling parent "luminousone" <rd.hunt gmail.com> writes:
On Monday, 5 August 2013 at 20:45:47 UTC, Borislav Kosharov wrote:
 On Monday, 5 August 2013 at 19:58:21 UTC, ron wrote:
 On Monday, 5 August 2013 at 08:46:54 UTC, Andre Artus wrote:
 On Monday, 5 August 2013 at 06:28:12 UTC, luminousone wrote:
 perhaps a more generic solution should be looked at, extend 
 contracts to work with all scope blocks.

 switch(somenumber)
 in {
  ... before stuff ...
 }
 out {
  .... after stuff ...
 }
 body {
  case 1:
  in {
     ... etc ....
  }
  out {
     ... more etc ...
  }
  body {
     ...
  }
  case 2:
    // and so on
 }

 or perhaps

 for( int i = 0 ; i < 10 ; i ++ )
 in {
  assert( i == 0 );
 }
 out {
  assert( i == 9 );
 }
 body {
 ... stuff ...
 }

 if it is desired for a particular contract block to be 
 called in release builds perhaps a attribute label to mark 
 it as a runtime block or something similar.

 foreach( i, k ; somerange )
  runtime in {
 ...
 }
 body {
 }
Please do not take offense, but I do not see this as a good idea. Contracts have a very different function; not just in D, but every language that uses them. The idea is to support design-by-contract programming. Overloading the constructs for the purposes proposed here would, in my opinion, cause confusion and/or weaken the proper use of contract programming. The code in the contract conditions should never do anything more than what is necessary to specify the contract. It should not do explicit IO (other than implied by assert()), mutate state, or anything like that. At the bottom of this page you can find a reading list for more info. http://www.digitalmars.com/d/dbc.html Or for a general overview: http://en.wikipedia.org/wiki/Design_by_contract Walter, does the D compiler or any of it's companion tools do any static analysis on the contracts? Such as a void safety/null reference check?
None taken, =-p. I don't see how this is different from current contract usage, right now they apply to function scopes only. currently I believe you could get a similar effect via using an inner function. void a() { int i = 0; void b() in { assert( i == 0 ); } out { assert( i == 10 ); } body { for( ; i < 10 ; i ++ ) { ... do something ... } } b(); }
Speaking of contracts, and reading the docs I see: "Pre and Post Contracts The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has..." So are contracts possible outside function declarations? For example just scopes or random places in code.
I being zero is the precondition for that loop, and i being 10 is the post condition for that loop. Pretty much I think that any scope can potentially fit the definition for contracts. Really any block of code, can be considered to have pre and post conditions, functions just happen to be one way to organize code.
Aug 05 2013
prev sibling parent "Andre Artus" <andre.artus gmail.com> writes:
 Borislav Kosharov wrote:

 Speaking of contracts, and reading the docs I see:
 "Pre and Post Contracts

 The pre contracts specify the preconditions before a statement 
 is executed. The most typical use of this would be in 
 validating the parameters to a function. The post contracts 
 validate the result of the statement. The most typical use of 
 this would be in validating the return value of a function and 
 of any side effects it has..."

 So are contracts possible outside function declarations? For 
 example just scopes or random places in code.
They should not be. Other than the 'invariant' which is on the class/interface.
Aug 05 2013
prev sibling parent reply "Andre Artus" <andre.artus gmail.com> writes:
On Monday, 5 August 2013 at 19:58:21 UTC, ron wrote:
 On Monday, 5 August 2013 at 08:46:54 UTC, Andre Artus wrote:
 On Monday, 5 August 2013 at 06:28:12 UTC, luminousone wrote:
 perhaps a more generic solution should be looked at, extend 
 contracts to work with all scope blocks.

 switch(somenumber)
 in {
   ... before stuff ...
 }
 out {
   .... after stuff ...
 }
 body {
   case 1:
   in {
      ... etc ....
   }
   out {
      ... more etc ...
   }
   body {
      ...
   }
   case 2:
     // and so on
 }

 or perhaps

 for( int i = 0 ; i < 10 ; i ++ )
 in {
   assert( i == 0 );
 }
 out {
   assert( i == 9 );
 }
 body {
  ... stuff ...
 }

 if it is desired for a particular contract block to be called 
 in release builds perhaps a attribute label to mark it as a 
 runtime block or something similar.

 foreach( i, k ; somerange )
  runtime in {
 ...
 }
 body {
 }
Please do not take offense, but I do not see this as a good idea. Contracts have a very different function; not just in D, but every language that uses them. The idea is to support design-by-contract programming. Overloading the constructs for the purposes proposed here would, in my opinion, cause confusion and/or weaken the proper use of contract programming. The code in the contract conditions should never do anything more than what is necessary to specify the contract. It should not do explicit IO (other than implied by assert()), mutate state, or anything like that. At the bottom of this page you can find a reading list for more info. http://www.digitalmars.com/d/dbc.html Or for a general overview: http://en.wikipedia.org/wiki/Design_by_contract Walter, does the D compiler or any of it's companion tools do any static analysis on the contracts? Such as a void safety/null reference check?
None taken, =-p. I don't see how this is different from current contract usage, right now they apply to function scopes only. currently I believe you could get a similar effect via using an inner function. void a() { int i = 0; void b() in { assert( i == 0 ); } out { assert( i == 10 ); } body { for( ; i < 10 ; i ++ ) { ... do something ... } } b(); }
I could be missing something, if so please clarify. The construct I have issue with is this one,
 switch(somenumber)
 in {
   ... before stuff ...
 }
 out {
   .... after stuff ...
 }
I would contend that code within in/out/invariant blocks should be 'pure' (no state changes, no IO [other than assert throwing]), it's only there to validate that a class and it's methods do not violate certain conditions. They should be able to be stripped out of the release build without altering the execution of the application in any way. A classic example is the null dereference check, which some compilers and most (all?) static analysers can detect. string whoIsAMonkey(Person p) in { assert(p !is null, "Person can not be null"); assert(!isNullOrEmpty(p.Name), "Person name can not be null or empty"); } body { return p.Name ~ " is a monkey!"; } void main() { Person p = null; // Compiler / analyser should complain with // "Person can not be null" writeln(whoIsAMonkey(p)); // ^ here } void main() { Person p = new Person(); // Compiler / analyser should complain with // "Person name can not be null or empty" writeln(whoIsAMonkey(p)); } etc. Contracts are meant to define the public (*) interface of a class. * By public I mean here anything not 'private', e.g. 'protected' for inheritance. As Andrei points out in his book ("The D Programming Language") contracts are not used to validate/scrub user (or any external) input as they can be compiled out of the executable. Contracts are there to check sanity at compile time, or at the very least during testing. The contract is (or should be) part of the documentation.
Aug 05 2013
parent reply "luminousone" <rd.hunt gmail.com> writes:
On Monday, 5 August 2013 at 21:48:46 UTC, Andre Artus wrote:
 On Monday, 5 August 2013 at 19:58:21 UTC, ron wrote:
 On Monday, 5 August 2013 at 08:46:54 UTC, Andre Artus wrote:
 On Monday, 5 August 2013 at 06:28:12 UTC, luminousone wrote:
 perhaps a more generic solution should be looked at, extend 
 contracts to work with all scope blocks.

 switch(somenumber)
 in {
  ... before stuff ...
 }
 out {
  .... after stuff ...
 }
 body {
  case 1:
  in {
     ... etc ....
  }
  out {
     ... more etc ...
  }
  body {
     ...
  }
  case 2:
    // and so on
 }

 or perhaps

 for( int i = 0 ; i < 10 ; i ++ )
 in {
  assert( i == 0 );
 }
 out {
  assert( i == 9 );
 }
 body {
 ... stuff ...
 }

 if it is desired for a particular contract block to be 
 called in release builds perhaps a attribute label to mark 
 it as a runtime block or something similar.

 foreach( i, k ; somerange )
  runtime in {
 ...
 }
 body {
 }
Please do not take offense, but I do not see this as a good idea. Contracts have a very different function; not just in D, but every language that uses them. The idea is to support design-by-contract programming. Overloading the constructs for the purposes proposed here would, in my opinion, cause confusion and/or weaken the proper use of contract programming. The code in the contract conditions should never do anything more than what is necessary to specify the contract. It should not do explicit IO (other than implied by assert()), mutate state, or anything like that. At the bottom of this page you can find a reading list for more info. http://www.digitalmars.com/d/dbc.html Or for a general overview: http://en.wikipedia.org/wiki/Design_by_contract Walter, does the D compiler or any of it's companion tools do any static analysis on the contracts? Such as a void safety/null reference check?
None taken, =-p. I don't see how this is different from current contract usage, right now they apply to function scopes only. currently I believe you could get a similar effect via using an inner function. void a() { int i = 0; void b() in { assert( i == 0 ); } out { assert( i == 10 ); } body { for( ; i < 10 ; i ++ ) { ... do something ... } } b(); }
I could be missing something, if so please clarify. The construct I have issue with is this one,
 switch(somenumber)
 in {
  ... before stuff ...
 }
 out {
  .... after stuff ...
 }
I would contend that code within in/out/invariant blocks should be 'pure' (no state changes, no IO [other than assert throwing]), it's only there to validate that a class and it's methods do not violate certain conditions. They should be able to be stripped out of the release build without altering the execution of the application in any way. A classic example is the null dereference check, which some compilers and most (all?) static analysers can detect. string whoIsAMonkey(Person p) in { assert(p !is null, "Person can not be null"); assert(!isNullOrEmpty(p.Name), "Person name can not be null or empty"); } body { return p.Name ~ " is a monkey!"; } void main() { Person p = null; // Compiler / analyser should complain with // "Person can not be null" writeln(whoIsAMonkey(p)); // ^ here } void main() { Person p = new Person(); // Compiler / analyser should complain with // "Person name can not be null or empty" writeln(whoIsAMonkey(p)); } etc. Contracts are meant to define the public (*) interface of a class. * By public I mean here anything not 'private', e.g. 'protected' for inheritance. As Andrei points out in his book ("The D Programming Language") contracts are not used to validate/scrub user (or any external) input as they can be compiled out of the executable. Contracts are there to check sanity at compile time, or at the very least during testing. The contract is (or should be) part of the documentation.
You are correct. I will have to check out his book.
Aug 05 2013
parent "Andre Artus" <andre.artus gmail.com> writes:
 As Andrei points out in his book ("The D Programming 
 Language") contracts are not used to validate/scrub user (or 
 any external) input as they can be compiled out of the 
 executable.

 Contracts are there to check sanity at compile time, or at the 
 very least during testing.

 The contract is (or should be) part of the documentation.
You are correct. I will have to check out his book.
Be sure to check out the errata page http://erdani.com/tdpl/errata/
Aug 05 2013
prev sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 05.08.2013 08:28, schrieb luminousone:
 or perhaps

 for( int i = 0 ; i < 10 ; i ++ )
 in {
       assert( i == 0 );
 }
 out {
       assert( i == 9 );
 }
 body {
      ... stuff ...
 }
that is just evil code if you got something todo before or on the first item of the list do it before the loop - and for the last behind the for loop if we talk about code-duplication then - use an inner function this type of sub-branching "de-looping" is slow (if performance is relevant) and just not foreach-able, and so not functional-style programming - its called "for loop index micro management for unknown reasons" - but many programmers prefer it very much :)
Aug 05 2013
next sibling parent reply "QAston" <qaston gmail.com> writes:
On Monday, 5 August 2013 at 09:37:11 UTC, dennis luehring wrote:

 this type of sub-branching "de-looping" is slow (if performance 
 is relevant) and just not foreach-able, and so not 
 functional-style programming - its called "for loop index micro 
 management for unknown reasons" - but many programmers prefer 
 it very much :)
It's caused by lack of inner functions in many languages - people use switch+flags or for loops to be more DRY.
Aug 05 2013
parent reply "Andre Artus" <andre.artus gmail.com> writes:
On Monday, 5 August 2013 at 11:32:14 UTC, QAston wrote:
 On Monday, 5 August 2013 at 09:37:11 UTC, dennis luehring wrote:

 this type of sub-branching "de-looping" is slow (if 
 performance is relevant) and just not foreach-able, and so not 
 functional-style programming - its called "for loop index 
 micro management for unknown reasons" - but many programmers 
 prefer it very much :)
It's caused by lack of inner functions in many languages - people use switch+flags or for loops to be more DRY.
I was under the impression that D has nested functions, unless by inner function you mean something else.
Aug 05 2013
parent reply "QAston" <qaston gmail.com> writes:
 I was under the impression that D has nested functions, unless 
 by inner function you mean something else.
Yeah, pardon my terminology.
Aug 06 2013
parent "Andre Artus" <andre.artus gmail.com> writes:
On Tuesday, 6 August 2013 at 07:44:46 UTC, QAston wrote:
 I was under the impression that D has nested functions, unless 
 by inner function you mean something else.
Yeah, pardon my terminology.
Not an issue, they normally mean the same thing. I believe JS's use case can be covered easily and clearly using a nested function taking a void delegate. With the not insubstatial benefit of being easier to debug.
Aug 06 2013
prev sibling parent "Andre Artus" <andre.artus gmail.com> writes:
On Monday, 5 August 2013 at 09:37:11 UTC, dennis luehring wrote:
 Am 05.08.2013 08:28, schrieb luminousone:
 or perhaps

 for( int i = 0 ; i < 10 ; i ++ )
 in {
      assert( i == 0 );
 }
 out {
      assert( i == 9 );
 }
 body {
     ... stuff ...
 }
that is just evil code if you got something todo before or on the first item of the list do it before the loop - and for the last behind the for loop if we talk about code-duplication then - use an inner function this type of sub-branching "de-looping" is slow (if performance is relevant) and just not foreach-able, and so not functional-style programming - its called "for loop index micro management for unknown reasons" - but many programmers prefer it very much :)
I have been programming since '92 and I must say that I have never seen this before. Maybe I've just been lucky, but this kind of thing would never pass a review anywhere I have worked before. Code is a user interface, if the user's model differs from the system model you will get errors. I.e. Junior von Newhire should be able to correctly reason about any piece of the code from day one. If they cannot do so they will introduce bugs.
Aug 05 2013
prev sibling parent reply "MattCodr" <mattcoder hotmail.com> writes:
On Monday, 5 August 2013 at 04:07:55 UTC, Andre Artus wrote:
 Andre Artus:
 int number;
 string message;
 switch (number)
 {
 	default: // valid: ends with 'throw'
 		throw new Exception("unknown number");
 	case 3:
 		message ~= "three "; break;
 	case 4:
 		message ~= "four "; continue;
 	case 5:
 		message ~= "five "; goto case;
 	case 6:
 		message ~= "six "; break;
 	case 1:
 	case 2:
 		message = "one or two";
 }

 With the inclusion of 'default' the condition covers the 
 whole range of 'int'. The programmer may only want the pre  
 and post code to be executed for every other case (1..6).
 MattCoder:
 Like I said, it would be nice if we could extend some D 
 features without change the compiler source, maybe like macros 
 in LISP.
It may not always be the case, but in my experience this often leads to write-only code. I'm pretty new to D, so I'm not quite up to speed with the metaprogramming abilities, but I'm under the impression that this is what mixin's are for.
Well I'm not experienced too, but mixin's for what I know just works in compiler time right? But anyway it would be possible to write my own switch version with mixin? I really would like to see this. Matheus.
Aug 05 2013
parent "Andre Artus" <andre.artus gmail.com> writes:
 Andre Artus:

 It may not always be the case, but in my experience this often 
 leads to write-only code.
 I'm pretty new to D, so I'm not quite up to speed with the 
 metaprogramming abilities, but I'm under the impression that 
 this is what mixin's are for.
 MattCoder:

 Well I'm not experienced too, but mixin's for what I know just 
 works in compiler time right?

 But anyway it would be possible to write my own switch version 
 with mixin? I really would like to see this.

 Matheus.
Yes, it takes any string that's valid D. I see people using it to embed domain specific languages (e.g. PEG via PEGGED) so you should easily be able to write a translator/preprocessor that takes your switch and converts it to D code. mixin(" switch (number) { default: // valid: ends with 'throw' throw new Exception("unknown number"); common_entry: // some common entry code break; common_exit: // some common exit code break; case 3: message ~= "three "; break; case 4: message ~= "four "; continue; case 6: message ~= "six "; break; } "); The preprocessor could rewrite to this string: " switch (number) { case 3: case 4: case 6: // some common entry code break; } switch (number) { default: // valid: ends with 'throw' throw new Exception("unknown number"); case 3: message ~= "three "; break; case 4: message ~= "four "; continue; case 6: message ~= "six "; break; } switch (number) { case 3: case 4: case 6: // some common exit code break; } " **** I do not recommend anyone do this **** The reason I would not recommend this is that it leads to brittle code that is hard to debug and reason about. The reason I use `switch`, and not `if` for the entry and exit code is because these should only fire under the same conditions as the cases in the original switch, otherwise you introduce hard to find bugs in your code. Once again, I do not recommend people doing this: my preference is for code that makes the programmers intent clear and explicit.
Aug 05 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, August 03, 2013 14:25:24 H. S. Teoh wrote:
 On Sat, Aug 03, 2013 at 01:33:44PM -0700, Jonathan M Davis wrote:
 The only thing that's really missing from C++ that D has that you
 might use in place of scope is finally.
Truth be told, I think scope trumps finally because it localizes the cleanup statement to the initialization. Sprinkling related code across two different places is more fragile and bug-prone.
Yes. There are lots of places where scope(exit) is far better than finally. It's just that aside from scope statements, the only related feature that C++ lacks is finally (and scope(exit) uses finally underneath the hood).
 C++ has RAII just like D does.  There's a much bigger difference when
 comparing against languages which don't have RAII (such as Java or

Yeah, I think I mostly had C in mind when I wrote what I did. :)
Yeah. The lack of RAII and scope in C is truly painful. I'm very glad that I've never had to write much pure C code.
 I definitely use scope from time to time, but I don't know how
 frequently I use it in comparison to how often I should use it. I was
 actually using scope(success) more until someone pointed out that
 there's an efficiency hit with that as it was putting try-catch blocks
 in places where there wouldn't have been before (as opposed to
 scope(exit) or scope(failure) where you'd be using try-catch blocks if
 you weren't using scope).
[...] Hmm, I never thought of that. So that limits the use cases of scope guards even more. :-P
Yeah. For instance, I'd made it so that RedBlackTree was using scope(success) for mutating its length in a few places, which helped make the code cleaner (because you didn't have to worry about incrementing the length at each of the various return statements), but that introduced try-catch blocks where there otherwise wouldn't have been any, and that code definitely needs to be as efficient as possible, so the scope(success) statements were removed from there. Other code wouldn't care as much, but for something like RedBlackTree, it really matters. It is a bit of a shame though, since it made the code cleaner. - Jonathan M Davis
Aug 03 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Aug 03, 2013 at 02:34:51PM -0700, Jonathan M Davis wrote:
 On Saturday, August 03, 2013 14:25:24 H. S. Teoh wrote:
 On Sat, Aug 03, 2013 at 01:33:44PM -0700, Jonathan M Davis wrote:
[...]
 I definitely use scope from time to time, but I don't know how
 frequently I use it in comparison to how often I should use it. I
 was actually using scope(success) more until someone pointed out
 that there's an efficiency hit with that as it was putting
 try-catch blocks in places where there wouldn't have been before
 (as opposed to scope(exit) or scope(failure) where you'd be using
 try-catch blocks if you weren't using scope).
[...] Hmm, I never thought of that. So that limits the use cases of scope guards even more. :-P
Yeah. For instance, I'd made it so that RedBlackTree was using scope(success) for mutating its length in a few places, which helped make the code cleaner (because you didn't have to worry about incrementing the length at each of the various return statements), but that introduced try-catch blocks where there otherwise wouldn't have been any, and that code definitely needs to be as efficient as possible, so the scope(success) statements were removed from there. Other code wouldn't care as much, but for something like RedBlackTree, it really matters. It is a bit of a shame though, since it made the code cleaner.
[...] On second thoughts, why is scope(success) implemented as try/catch? Shouldn't the compiler be able to insert it before the end of each block instead? Stack-unwinding bypasses the end of block code, so the only way you can get there is by successful exit. T -- Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
Aug 03 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, August 03, 2013 14:49:30 H. S. Teoh wrote:
 On Sat, Aug 03, 2013 at 02:34:51PM -0700, Jonathan M Davis wrote:
 On Saturday, August 03, 2013 14:25:24 H. S. Teoh wrote:
 On Sat, Aug 03, 2013 at 01:33:44PM -0700, Jonathan M Davis wrote:
[...]
 I definitely use scope from time to time, but I don't know how
 frequently I use it in comparison to how often I should use it. I
 was actually using scope(success) more until someone pointed out
 that there's an efficiency hit with that as it was putting
 try-catch blocks in places where there wouldn't have been before
 (as opposed to scope(exit) or scope(failure) where you'd be using
 try-catch blocks if you weren't using scope).
[...] Hmm, I never thought of that. So that limits the use cases of scope guards even more. :-P
Yeah. For instance, I'd made it so that RedBlackTree was using scope(success) for mutating its length in a few places, which helped make the code cleaner (because you didn't have to worry about incrementing the length at each of the various return statements), but that introduced try-catch blocks where there otherwise wouldn't have been any, and that code definitely needs to be as efficient as possible, so the scope(success) statements were removed from there. Other code wouldn't care as much, but for something like RedBlackTree, it really matters. It is a bit of a shame though, since it made the code cleaner.
[...] On second thoughts, why is scope(success) implemented as try/catch? Shouldn't the compiler be able to insert it before the end of each block instead? Stack-unwinding bypasses the end of block code, so the only way you can get there is by successful exit.
Hmmm. For a scope(success) statement to work, the code has to be put at every successful exit point from the scope. In the simple case, that means putting it at the end of the try portion of a try-catch block, but the try-catch isn't strictly necessary if there is no scope(failure) or scope(exit) - though I don't know what dmd currently does. Where scope(success) is useful is when you have multiple return statements and want something to occur when they return before exiting the function (or possibly the same thing but with break or continue statements inside a loop). In that case, try-catch doesn't help at all, beacause in all cases, you're forced to either duplicate the code in the scope(success) block at each point that the code exits the scope or have a common block with a goto at each exit point. Yeah. I don't see any need for try-catch there. So, it shouldn't be a problem. I know that it was discussed with regards to a pull for RedBlackTree, but I don't think that it was a long discussion, and I guess that it wasn't long enough. Thinking through it now, I really don't see a problem with it (though maybe I'm missing something). But I'd have to investigate what dmd actually does to see what the actual efficiency impact is. It wouldn't surprise me at all if dmd currently inserts useless try-catch blocks or something like that (though hopefully it doesn't). But assuming that dmd's implementation is appropriately efficient, I don't see any problem with scope(success), so I may start using it again (though I should probably investigate what code it generates first). - Jonathan M Davis
Aug 03 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Aug 03, 2013 at 03:18:49PM -0700, Jonathan M Davis wrote:
[...]
 Hmmm. For a scope(success) statement to work, the code has to be put
 at every successful exit point from the scope. In the simple case,
 that means putting it at the end of the try portion of a try-catch
 block, but the try-catch isn't strictly necessary if there is no
 scope(failure) or scope(exit) - though I don't know what dmd currently
 does.
 
 Where scope(success) is useful is when you have multiple return
 statements and want something to occur when they return before exiting
 the function (or possibly the same thing but with break or continue
 statements inside a loop).  In that case, try-catch doesn't help at
 all, beacause in all cases, you're forced to either duplicate the code
 in the scope(success) block at each point that the code exits the
 scope or have a common block with a goto at each exit point.
 
 Yeah. I don't see any need for try-catch there. So, it shouldn't be a
 problem. 

 I know that it was discussed with regards to a pull for RedBlackTree,
 but I don't think that it was a long discussion, and I guess that it
 wasn't long enough. Thinking through it now, I really don't see a
 problem with it (though maybe I'm missing something). But I'd have to
 investigate what dmd actually does to see what the actual efficiency
 impact is. It wouldn't surprise me at all if dmd currently inserts
 useless try-catch blocks or something like that (though hopefully it
 doesn't). But assuming that dmd's implementation is appropriately
 efficient, I don't see any problem with scope(success), so I may start
 using it again (though I should probably investigate what code it
 generates first).
[...] My guess is that dmd is using the finally block to implement code that runs before the function returns / scope exits. That's probably where the try/catch blocks are coming from. Not terribly efficient, but simpler to implement, I guess. T -- Chance favours the prepared mind. -- Louis Pasteur
Aug 04 2013