difference between x = Nullable.init and x.nullify
Stanislav Blinov via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Sat Jun 3 01:17:18 PDT 2017
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/aalafajtuhlvfirwfvea@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?..
More information about the Digitalmars-d-learn
mailing list