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