A couple of thoughts/queries.

Robby robby.lansaw at gmail.com
Wed Dec 12 20:34:26 PST 2007


Daniel Keep wrote:
> 
> Walter Bright wrote:
>> Robby wrote:
>>> Anyways, what I'm in hopes of finding is a way to tell the compiler
>>> that I never want null, ever. I want an instance of the class and
>>> that's that. The whole idea of taking every lil runtime hit for
>>> checking  and the code cruft for writing it when in fact it's
>>> something that seems to be easy for a compiler to do the work for me.
>> The hardware will do the check for null pointer for you every time you
>> do a dereference.
> 
> <summary>
> 
> Non-nullable types != null deref exceptions.
> Non-nullable types > null deref exceptions.
> Non-nullable types > contracts.
> 
> </summary>
> 
> <rant>
> 
> That's not the point.  Null dereference errors aren't all that helpful.
>  They tell you that something's gone wrong, but they don't tell you *why*.
> 
> Let's pretend for a moment that appending '@' to an object type makes it
> a non-nullable type.  For example:
> 
>     Object@ o = null;
> 
> That would be a *compile-time error* since Object at s cannot be null.  It
> also means that (in the general case) this won't work:
> 
>     Object o1 = new Object;
>     Object@ o2 = o1;
> 
> That's because o1 could possibly contain a null.  So in order to do
> this, you'd have to check that o1 is not null, and then cast.  Heck, the
> compiler could even do that for you:
> 
>     Object@ o2 = cast(@) o1
> 
> Why is this better than a null dereference exception?  Because it will
> throw the exception when you try to *introduce the null* into your
> program's state, *not* when you try to use it.  Normally, all a null
> dereference tells you is that somewhere along the line, you screwed up.
>  This tells you *when* you screw up.
> 
> What's more, this makes code cleaner, easier to check, and faster.
> Instead of having this all over the place:
> 
>     // the_object is a parameter, and could be null, so we'd best check
>     // it!  We can't assert directly or the check will be elided in
>     // -release builds.
>     if( the_object is null ) assert(false);
> 
> ....we need only check exactly once: where we introduce the object.
> After that, there's zero runtime cost, since we've already guaranteed
> that the reference is not null.  This is unlike contracts and invariants
> which exact an overhead, not to mention the fact that you can always
> either forget to write the assertion, or write it incorrectly.
> 
> Tim Sweeny (the lead programmer at Epic) once commented that the
> majority of bugs in the Unreal engine were caused by null dereferences;
> they knew the bugs were there, they just couldn't work out where the
> nulls were coming from.  He said he'd kill to have non-nullable objects
> in C++. [1]
> 
> This is something I've wanted for ages [2], if only for all the checks
> it would let me not write.  I understand that there are lots of things
> people want you to implement, and you can't fit them all in.  But don't
> mistake this for null dereference exceptions.
> 
> 	-- Daniel
> 
> [1] I'm recalling from memory; too tired to go tracking down the paper
> itself.  Something about the next big programming language for games.
> Incidentally, he put his money on a Haskell-style language with C-style
> syntax.  And non-nullable types. :P
> 
> [2] Actually, what I *really* want is some form of type constraints.
> Something like:
> 
>     alias real:{$ != 0 && $ == $} real_not_zero_or_nan;
> 
>     Assuming '$' means "current value".  At the moment, the best tool we
> have for this is, unfortunately, Hungarian notation (apps Hungarian, not
> that pointless system Hungarian.)
> 
> </rant>
Totally agree.

I was thinking more in the lines of having the 'contract' within the 
function/method declaration rather than having it with the object 
passing so that the api could have the final say, rather than the object 
passing in. And a storage class does have a backwards compat story 
without adding anything to the allowed identifier grammar.

I would just love to get out of the watch for and except loop that we 
always seem to be in.

I remember reading some where that dealing with nulls and exceptions 
therein is a lot like C and memory issues, and c++ has both dramas. I'm 
not overly C++ literate so I can't really comment.

In Ruby we tend to develop in a duck typing fashion, and since D is 
obviously statically typed, I'd love for the compiler to actually take 
care of some of the work for me, since it'll know anyways and i can 
delcare not wanting it.



More information about the Digitalmars-d mailing list