NotNull pointers

[Timon Gehr]

On 08/30/2011 11:07 PM, Walter Bright wrote:
> On 8/30/2011 7:58 AM, Christian Kamm wrote:
>> I want to point out the following bug in the example, because it's
>> *such* a
>> common problem and, in my opinion, one of D's warts:
>>
>> Walter Bright wrote:
>>> this(P q)
>>> {
>>> assert(q);
>>> p = q;
>>> }
>>
>> Try
>> auto d = NotNull!Object(null);
>>
>> you'll get a segmentation fault and not an assert. That's because
>> assert(someclass) does not check if someclass is non-null at all, it
>> verifies its invariant instead!
>>
>> All the asserts should be assert(q !is null);.
>
> Is it really a bug? If you compile in release mode, and q is null, and
> you use !is null, you'll get a processor hardware halt. Halt or seg
> fault - there's not much practical difference.

You mean, in release mode the assert gets compiled out, and it seg 
faults in the code sequence that depends on the assertion, right?

>
> As I've said many times, I really don't understand the fear of seg
> faults. The important thing is that the program stop running as near as
> possible to the source of the error. Whether it stops because of a
> software detected error or a hardware detected error is simply not
> relevant.
>

I am not afraid of seg faults so much, but in debug mode it is certainly 
an annoyance, because you don't get the source line and stack trace. I'd 
say it would be really nice if assert(classreference); would never seg 
fault during debugging. Is there any practical use for manually running 
the class invariant?