(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