On Saturday, 3 June 2017 at 08:01:14 UTC, Jonathan M Davis wrote:
On Saturday, June 03, 2017 06:41:44 Stanislav Blinov via
Digitalmars-d-learn wrote:
On Saturday, 3 June 2017 at 06:19:29 UTC, Jonathan M Davis
wrote:
> looking at what rt_finalize does, I don't see why it
> couldn't be nothrow. So, unless I'm missing something, it
> seems like that would be a good enhancement.
>
> - Jonathan M Davis
Presently, rt_finalize cannot be made nothrow, or un-made
@system, because "reasons":
http://forum.dlang.org/thread/aalafajtuhlvfirwf...@forum.dlang.org
Fixing that would require significant changes to the runtime,
and probably the compiler. I don't think it qualifies as a
simple "enhancement" :)
Well, as I said, I could be missing something, but all
rt_finalize does is call rt_finalize2, and rt_finalize2 _is_
nothrow (it catches any Exceptions that are thrown by the
destructor/finalizer). So, I have no idea why it would be the
case that rt_finalize couldn't be nothrow, and I saw nothing in
that thread which contradicts that, but I could have read it
too quickly. Regardless, it's a perfectly valid enhancement
request whether it's easy to implement or not.
- Jonathan M Davis
Whoops, my bad, I forgot it indeed swallows exceptions and does
the onFinalizeError instead. So... yep, then it seems that
rt_finalize probably should be marked nothrow too. Hmm... if
throwing in a destructor is considered a runtime error, perhaps
another valid enhancement would be to statically disallow
throwing Exceptions in destructors, i.e. *require* them be
nothrow?..
