Spec#, nullables and more

Pelle Månsson pelle.mansson at gmail.com
Fri Nov 5 17:07:22 PDT 2010


On 11/06/2010 12:41 AM, Walter Bright wrote:
> Denis Koroskin wrote:
>> On Fri, 05 Nov 2010 23:44:58 +0300, Walter Bright
>> <newshound2 at digitalmars.com> wrote:
>>>
>>> To eliminate null pointers is the same as shooting the canary in your
>>> coal mine because its twitter annoys you.
>>
>> I'm tired of pointing out that NO ONE is talking about eliminating
>> null pointers, but rather extending an existing type system to support
>> non-nulls. Your hate towards non-nullables comes from misunderstanding
>> of the concept.
>
> Consider non-nullable type T:
>
> T[] a = new T[4];
> ... time goes by ...
> T[1] = foo;
> T[3] = bar;
> ... more time goes by ...
> bar(T[2]);
>
> In other words, I create an array that I mean to fill in later, because
> I don't have meaningful data for it in advance. What do I use to default
> initialize it with non-nullable data? And once I do that, should
> bar(T[2]) be an error? How would I detect the error?
>
> In general, for a non-nullable type, how would I mark an instance as not
> having meaningful data?
>
> For example, an int is a non-nullable type. But there's no int value
> that means "no meaningful value", and this can hide an awful lot of bugs.
>
> I'm not sure at all that non-nullable types do more than make easy to
> find bugs much, much harder to find.

I tried to find a good analogy but failed, so I'll just say that in the 
case you presented you would obviously not use a non-nullable type. As, 
you know, you wanted nulls in the array.

We're using signalling nans to get rid of the null-ish thing for floats, 
as well.


More information about the Digitalmars-d mailing list