On Wednesday, 28 September 2016 at 21:00:00 UTC, Steven
Schveighoffer wrote:
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.
Assuming for a minute that we want some form of DIP1002, we might
be able to extend the `try` scope in an interesting way:
try {
auto f = foo();
}
catch (Exception) {
...
}
finally (bool ok) { // true if no exception
bar();
__guard (ok) f.baz();
f.baz(); // error: f not in scope
}
Here the guard statement is a runtime check of `ok`, but it has
the compile-time effect of enabling the `try` scope to be
extended. Obviously this is a bit extreme if it was the only use
of the guard statement, but the guard statement could be useful
in other situations too (e.g. non-null code checked at
compile-time).
Note that finally(bool) is more flexible than finally/else as you
can interleave code arbitrarily. __guard makes it clearer
something special is happening rather than just implicitly
extending `try` scope in the `else` clause. Also, 'else' is not
clear enough IMO.
