On Monday, 5 June 2017 at 10:09:30 UTC, ketmar wrote:
tbh, i think that it adds Yet Another Exception Rule to the
language, and this does no good in the long run. "oh, you
generally cannot do that, except if today is Friday, it is
rainy, and you've seen pink unicorn at the morning." the more
exceptions to general rules language has, the more it reminds
Dragon Poker game from Robert Asprin books.
Fair enough. A few counterpoints:
- This one special case is pretty self-contained. It doesn't
require adding annotations (unlike, say, DIP PR #61*), won't
impact code that doesn't use it, and the users most likely to
hear about it are the one who need to recover from Errors in
their code.
- It doesn't introduce elaborate under-the-hood tricks (unlike
DIP 1008*). It uses already-existing concepts (@safe and @pure),
and is in fact closer to the intuitive logic behind Error
recovery than the current model; instead of "You can't recover
from Errors" you have "You can't recover from Errors unless you
flush all data that might have been affected by it".
*Note that I am not making a statement for or against those DIPs.
I'm only using them as examples to compare my proposal against.
So while this would add feature creep to the language, but I'd
argue that feature creep would be pretty minor and
well-contained, and would probably be worth the problem it would
solve.
