On Thursday, 17 January 2013 at 00:41:17 UTC, Stewart Gordon
wrote:
The OP was talking about scope(success), not scope(exit).
scope(success), by definition, won't be executed if the code
fails. If it does it by changing it to a try/finally, it has
to generate extra code to test whether the code succeeded or
not. It's far simpler to just write out the scope(success)
code at the end of the scope in question. As such, the
compiler is _pessimising_ the code.
I am aware of that. And although the examples were scope(exit)
doesn't change how it's rewritten, only if finally is used.
Depending on how much unrolling there is it might not be worth
trying to reduce the try/catches, 3 scope levels as it is can be
very hard to write correctly.
OK, so it's a bit more complicated if the scope can be exited
via a return, break, continue or (dare I mention?) goto
statement, but even then it ought to be quite easy to make the
compiler generate more efficient code.
Not everything that seems obvious to us is easy to write for a
computer to recognize; Who knows perhaps the compiler having one
'success' code may end up more efficiently managed by making it a
delegate/lambda instead and calling it at each point rather than
inlining the code to handle all code paths.
This should be fixed, as it is discouraging use of
scope(success).
I'll agree, if something can't throw in a given scope then it
should be able to remove the try/catches (as much as possible),
and if scope(failure) can never be called it should be removed
(although a warning might be nice as notification, a hint of a
bug perhaps?)
