null [re: spec#]

["Jérôme M. Berger"]

steveh wrote:
> Non-null types add terrible runtime checks everywhere.
> 
	No they don't. They *remove* runtime checks everywhere.

There are only two possible situations for a given pointer:

1. You know that it cannot be null. In that case, you use a
non-nullable type for that pointer to give the information to the
compiler. The compiler can then use this information to optimize
code better (for example removing null checks inside template
instantiations);

2. You don't know if a pointer may be null. In that case, you must
check that pointer anyway before using it, so you use a nullable
pointer and you're back in the current situation except that the
compiler knows to warn you if you forget to check.



	So what do you gain? Several things:

1. As a library writer, if your function cannot work with a null
input, instead of checking the function argument and erroring if it
is null, you just use a non-nullable type which pushes the check in
the user code where it can be removed altogether in lots of cases;

2. Generic code (templates and mixins) may be optimized better: when
generic code includes a null check, the compiler can remove it if it
is applied to a non-nullable type;

3. And overall, you get safer code because if you forget to check a
nullable pointer, then the compiler can tell you.



	Note that adding non-nullable types has *nothing* to do with
automatically adding hidden runtime checks. I personally think that
adding such checks automatically is a bad idea in a "system"
language. The proper behaviour should be for the compiler to give an
error message (*) so that the programmer can take a look and choose
between using a check or changing to a non-nullable pointer.

		Jerome

(*) I didn't say a warning, because I know Walter's view on them,
but it could be a warning instead of an error.
-- 
mailto:jeberger at free.fr
http://jeberger.free.fr
Jabber: jeberger at jabber.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101106/18dd193e/attachment.pgp>