(non)nullable types

Christopher Wright dhasenan at gmail.com
Sun Feb 15 05:54:20 PST 2009


Nick Sabalausky wrote:
> "Christopher Wright" <dhasenan at gmail.com> wrote in message 
> news:gn7jn9$1i0e$1 at digitalmars.com...
>> class Foo {
>>     void delegate()? dg;
>>     void doStuff() {
>>         if (dg) {
>>             doPart1;
>>             doPart2;
>>         } else {
>>             // some other long code path
>>         }
>>     }
>>
>>     private void doPart1() {
>>         // use dg; why should I check?
> 
> Because some other function or codepath could still accidentally be breaking 
> your precondition convention, so you're right back to inviting hidden.

Yes, but I'm using nullable variables. I'm happy with getting a hardware 
exception if I try dereferencing them when they're null.

I could pass the non-nullable versions to each of these convenience 
functions, which works in small cases (one or two such variables) and 
totally eliminates the value of using member functions. Plus, that's 
code duplication.

As for checking every time...

It's code duplication.

It's slower than removing the checks, and the checks aren't removed in 
release mode.

The checks are all going to boil down to:
if (variable) { } else { assert (false); }

It's unnecessary.

It's the compiler assuming that the programmer is an idiot and not 
allowing the programmer to insist that they know what they're doing.

I want *warnings* about this. But I think it's going to require far too 
much boilerplate in complex circumstances.



More information about the Digitalmars-d mailing list