Is Nullable supposed to provide Optional semantics?

[Steven Schveighoffer]

On 12/30/17 3:59 AM, Chris Paulson-Ellis wrote:
> On Friday, 29 December 2017 at 22:08:59 UTC, vit wrote:
>>     n = Nullable!Object.init;
>>     assert(n.isNull == true);
>> [...]
>> more: 
>> https://forum.dlang.org/thread/jrdedmxnycbqzcprebjl@forum.dlang.org?page=1 
>>
> 
> Thanks.
> 
> No-one in the linked thread seemed to know why .destroy is used in 
> nullify. Looking at the commit history it used to be .clear, but maybe 
> that did the same thing, I don't know.

clear was renamed to destroy because clear typically is used in 
containers to remove all elements (but not destroy the container 
itself). Since clear was a UFCS function, it led to confusion:

somestruct.clear; // equivalent to clear(somestruct), destroys it.
container.clear; // remove all elements
clear(container); // destroy the container

So destroy was used instead, and it's a much better name.

> I still think nullify is going beyond the Nullable remit for reference 
> types. Unless anyone disagrees, I'll submit a bug report.

I think you are correct. I believe it is calling destroy expecting it to 
work like calling destroy on a pointer (which does nothing I think, or 
just sets it to null). But it doesn't work that way.

What may have been missed by the others is that the call to toString 
that caused the segfault was NOT on the nullable `n`, but on the 
original object `o`. So nullifying the nullable kills any other 
references to the same object.

Please file a bug report.

-Steve