Spec#, nullables and more

[spir]

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


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

In D, a variable can be declared and not explicitely initialised. The problem is then, I guess: what bit pattern in memory should the language use to mean "I'm invalid, don't use me"? (-128 for signed bytes?). this is for runtime checking. NaN, in my opinion, precisely plays this role for floats.
See also (*)

Now, what about static checking? Is it at all possible for a compiler to statically catch every attempt to use a variable of undefined value (whatever its type)? Should symbol tables have a flag? Or how else do that?
Also, how to check all possible control flows pathes? Could there be linguistic means helping in that? I mean, syntactic constraints that would make it easy for the compiler (and the human reader as well!) to obviously know whether a variable is initialised or not at a given point in code? Esp. at func boundaries (parameters of calls, return values).


Denis


(*) Dynamic languages do not suffer of this issue the same way because one cannot introduce a variable without giving it a value; which is good. But then, programmers still need some placeholder meaning "undef", esp for structured type fields. For this, languages provide null/nil/none; this convention is possible because _variables_ are untyped. In this sense, null can play in those languages the role of element of a bottom type meaning undef I evoked in another post.

But a new problem arises due to the fact that those languages let one freely play with null and pass it around like any other value (or more generally assignable element). As a consequence, programmers use it like a meaningful element loaded with app semantics. Thus, in a sense, highjacking it for their own use, and breaking the intended purpose of the feature. I guess null should not be assignable, for instance; but instead the language should provide a way to introduce yet undefined vars, that would automatically be set to null by the language. (==> more or less the role of NaN in D for floats.)

When programmers need a special element to carry app semantics (eg "no author known" in a book database), they should define it especially -- not be able use null/nil/none instead. I think languages could provide a convenience type for those thingies (I call them "Marks"); the point is similar to some uses of enums: elements that have a sense but no value properly speaking.

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

spir.wikidot.com