On 9/28/16 4:18 PM, pineapple wrote:
On Wednesday, 28 September 2016 at 17:56:13 UTC, Steven Schveighoffer
wrote:
The more I think about this submission, I feel like the benefits are
quite slim.
This is not and was not intended to be a glorious, incredible addition
to the language. It is meant to shove D a couple inches further in the
direction of modern programming constructs. Everywhere a programmer can
use `else` instead of mucking about with a boolean success flag
The main question to answer is how big is this "Everywhere". I've never
needed it. This obviously isn't proof against, but the situation we are
solving here seems very small. Is it worth adding a construct to the
language and it seems here we are going to break valid code that already
uses else after catch to mean something else?
On Wednesday, 28 September 2016 at 17:56:13 UTC, Steven Schveighoffer
wrote:
For example, should it be valid to use "else" without a catch?
Yes.
Again, try {this} else {that} looks like "try this if it works, else
that", which is not what this really does. else only reads right if it
follows catch.
On Wednesday, 28 September 2016 at 17:56:13 UTC, Steven Schveighoffer
wrote:
The boolean to indicate an exception was thrown is cumbersome, but not
horrible. Having the compiler manage the boolean may make this cleaner
(e.g. finally(bool thrown)), I like it better than the else suggestion.
I think this would be an improvement over the current exception
handling, but `else` is a pre-existing concept and making `finally`
optionally accept a boolean this way tosses convention on its head, and
not in a way I think is desireable. If what you're looking for is a
clean solution, `finally(bool)` is definitely not it.
the pre-existing concept may work for Python, but not be OK for D (i.e.
breaks valid code). The boolean concept is how you would implement it by
hand, why does this toss it on its head? In fact, any code that requires
this kind of flow already uses this mechanism, and can basically be
updated to use the new concept by simply removing a few lines and
changing finally to finally(bool).
Moreover, Idan's suggestions about scope sharing make sense to me and I
don't think his line of thinking would be compatible with doing it the
way you suggest.
Declaring variables that you need in the right scopes is pretty
straightforward. Having scopes magically continue around other separate
scopes (catch scopes) doesn't look correct. I get why it's desired, but
it doesn't look clean at all.
-Steve
