Spec#, nullables and more

[spir]

On Fri, 05 Nov 2010 16:41:25 -0700
Walter Bright <newshound2 at digitalmars.com> wrote:

> 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.

Maybe the whole point is rather to catch variables left undefined (with a meaningful value) before use, isn't it?

I was first astonished by D's .init feature. Thought it's a bad idea, as it lets pass through unitialised vars; and worse, except for floats & pointers (maybe more), with a perfectly valid value for the type.
Also, when reading "int i;", there is no way to tell whether the programmer (including myself some time later) actually intends to initialise I with 0. So, I always write "int i=0;".

I understand there must be something in the var's memory cell, and rather fill it with zeroes or NaN than let it undefined. This aspect of the problem may mean that non-nullable (or more generally never undefined?) types cannot be a solution for languages that need to keep low-level control and efficiency like D.
On a language that can tolerate to be higher-level (from the above pov), where for instance all values can be referenced or even wrapped in a struct, then possibly there would be a solution. I would try to introduce a bottom type called eg UNDEF, which single value is thus valid for all types. This would be the unique .init. All operations would fail when passed UNDEF. (Except for a func or method expression() intended for programmer feedback.) Then, I guess it would be possible to do it so that each time a programmer tries to use an undefined value, whatever its type, they get "UndefError: attempt to use undefined variable...".

Is this the actual point of non-nullables? After all, we use null only to mean "currently undefined -- don't use me", don't we? Because there must be something in memory, and we don't want to let there random bits. If I not totally wrong, then I currently rather agree that non-nullables are not the proper tool for D -- but maybe there is no solution at all.
(Maybe I'm completely aside the actual question; but I wanted to ask, so that at least I know ;-)


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com