www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Nullable types

reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
Hi,

I'm getting more and more intrigued by the way Delight [1] and F# [2] handle 
nullable types: using the type-system to check for "nullness" the way it 
does for constness*. I haven't used either one of those two languages, but 
since having read about both systems, I can't help keeping a tag in my mind 
for each variable; "this one can be null", "this one can't be null"...

* Is there anybody with experience using this concept of nullness in F# or 
Delight?

* Are there any other languages with this concept?

* I personally think it would be nice for D too. Your opinions?

L.

PS. I have the feeling this also can be generalized, like the 
green-code-red-code system. It's like a compile-time tagging of variables, 
with some added syntactic sugar (the ?-token).

[1] http://delight.sourceforge.net/null.html
[2] http://research.microsoft.com/fsharp/manual/import-interop.aspx#Nullness
Oct 20 2008
next sibling parent reply samabeau <no-spam-for-sambeau mac.com> writes:
Lionello Lunesu Wrote:
 

 * Are there any other languages with this concept?



C# does. Nullable types have a question mark after them.
eg:-

int? num = null;

http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx
Oct 20 2008
next sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
samabeau wrote:

 Lionello Lunesu Wrote:
  

 * Are there any other languages with this concept?



 C# does. Nullable types have a question mark after them.
 eg:-
 
 int? num = null;
 
 http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx
 



In C#, that "?" basically wraps (boxes?) a value type into a reference 
type.

Once you have an object reference (either an instanced class or such a 
wrapped value type) you still must check for null everywhere you use it. 
And in some situations you just know it's never null and you would like 
to use that information.

At the moment, the way you can tell that an object is never null is by
(1) using an assertion;
(2) mentioning it in a comment;
(3) using some hungarian-like naming scheme;

None of which have any value at compile-time. In fact, if you think 
those 3 alternatives are good enough, you could drop all the 
compile-time type checking.

And what happens nowadays when none of those 3 is present? You check for 
null, whether the check makes sense or not. If I'd only get a penny for 
every if-null check I've encountered...

Letting the type system track whether a reference is null or not should 
result in more readable code. No more wondering "What if x is null? 
Where's it checked?" and no more "let's check for null, just in case."

L.
Oct 20 2008
next sibling parent reply Olli Aalto <oaalto gmail.com> writes:
Lionello Lunesu wrote:

 samabeau wrote:

 Lionello Lunesu Wrote:
  

 * Are there any other languages with this concept?



 C# does. Nullable types have a question mark after them.
 eg:-

 int? num = null;

 http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx



 In C#, that "?" basically wraps (boxes?) a value type into a reference 
 type.
 
 Once you have an object reference (either an instanced class or such a 
 wrapped value type) you still must check for null everywhere you use it. 
 And in some situations you just know it's never null and you would like 
 to use that information.
 
 At the moment, the way you can tell that an object is never null is by
 (1) using an assertion;
 (2) mentioning it in a comment;
 (3) using some hungarian-like naming scheme;
 
 None of which have any value at compile-time. In fact, if you think 
 those 3 alternatives are good enough, you could drop all the 
 compile-time type checking.
 
 And what happens nowadays when none of those 3 is present? You check for 
 null, whether the check makes sense or not. If I'd only get a penny for 
 every if-null check I've encountered...
 
 Letting the type system track whether a reference is null or not should 
 result in more readable code. No more wondering "What if x is null? 
 Where's it checked?" and no more "let's check for null, just in case."
 



In Objective-C you can call methods on null(nil in Obj-C) objects. The 
call is silently ignored. So no more crashes or NPEs.

The problem with this is that if you call a method on a null object and 
try to use the return value as an initializer for a local variable, it 
will be set to 0 for numbers, nil for objects, and so on. This can lead 
to hard to find bugs.

I'm not an expert Objective-C programmer, not even close, so I cannot 
say if this system is preferable to crashing the whole application.

O.
Oct 20 2008
parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Olli Aalto" <oaalto gmail.com> wrote in message 
news:gdhud3$1o0o$1 digitalmars.com...

 In Objective-C you can call methods on null(nil in Obj-C) objects. The 
 call is silently ignored. So no more crashes or NPEs.

 The problem with this is that if you call a method on a null object and 
 try to use the return value as an initializer for a local variable, it 
 will be set to 0 for numbers, nil for objects, and so on. This can lead to 
 hard to find bugs.



:-O That sounds disastrous!

Although it sounds like D's NaN initializer: if there's even one NaN 
somewhere in a big calculation, the result of the calculation will likely be 
NaN as well. And here it helps finding bugs.

Now, if only ints and object references had a real NaN equivalent.... :-)

L.
Oct 20 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Lionello Lunesu:

 Although it sounds like D's NaN initializer: if there's even one NaN 
 somewhere in a big calculation, the result of the calculation will likely be 
 NaN as well. And here it helps finding bugs.
 Now, if only ints and object references had a real NaN equivalent.... :-)



Again, see the Maybe of Haskell:
http://en.wikibooks.org/wiki/Haskell/Hierarchical_libraries/Maybe

Bye,
bearophile
Oct 20 2008
prev sibling parent Sergey Gromov <snake.scaly gmail.com> writes:
Tue, 21 Oct 2008 09:25:56 +0800,
Lionello Lunesu wrote:

 
 "Olli Aalto" <oaalto gmail.com> wrote in message 
 news:gdhud3$1o0o$1 digitalmars.com...

 In Objective-C you can call methods on null(nil in Obj-C) objects. The 
 call is silently ignored. So no more crashes or NPEs.

 The problem with this is that if you call a method on a null object and 
 try to use the return value as an initializer for a local variable, it 
 will be set to 0 for numbers, nil for objects, and so on. This can lead to 
 hard to find bugs.



 :-O That sounds disastrous!
 
 Although it sounds like D's NaN initializer: if there's even one NaN 
 somewhere in a big calculation, the result of the calculation will likely be 
 NaN as well. And here it helps finding bugs.



Yeah, I've spent some time hunting that NaN.  I wish I had an exception 
instead.
Oct 21 2008
prev sibling parent reply "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
Not true. It wraps the value type in a struct with a boolean field 
expressing whether it is null or not.

http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx

- Bent

"Lionello Lunesu" <lio lunesu.remove.com> skrev i meddelelsen 
news:gdhs01$1jnp$1 digitalmars.com...

 samabeau wrote:

 Lionello Lunesu Wrote:


 * Are there any other languages with this concept?



 C# does. Nullable types have a question mark after them.
 eg:-

 int? num = null;

 http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx



 In C#, that "?" basically wraps (boxes?) a value type into a reference 
 type.

 Once you have an object reference (either an instanced class or such a 
 wrapped value type) you still must check for null everywhere you use it. 
 And in some situations you just know it's never null and you would like to 
 use that information.

 At the moment, the way you can tell that an object is never null is by
 (1) using an assertion;
 (2) mentioning it in a comment;
 (3) using some hungarian-like naming scheme;

 None of which have any value at compile-time. In fact, if you think those 
 3 alternatives are good enough, you could drop all the compile-time type 
 checking.

 And what happens nowadays when none of those 3 is present? You check for 
 null, whether the check makes sense or not. If I'd only get a penny for 
 every if-null check I've encountered...

 Letting the type system track whether a reference is null or not should 
 result in more readable code. No more wondering "What if x is null? 
 Where's it checked?" and no more "let's check for null, just in case."

 L.
Oct 20 2008
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Bent Rasmussen wrote:

 Not true. It wraps the value type in a struct with a boolean field 
 expressing whether it is null or not.
 
 http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx



Indeed. Thanks for pointing that out.

So C#'s 'foo?' syntax has even less to do with this compile-time 
nullness checking.

L.
Oct 20 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Tue, Oct 21, 2008 at 9:11 AM, Lionello Lunesu <lio lunesu.remove.com> wrote:

 Bent Rasmussen wrote:

 Not true. It wraps the value type in a struct with a boolean field
 expressing whether it is null or not.

 http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx




 So C#'s 'foo?' syntax has even less to do with this compile-time nullness
 checking.



 Now it makes sense.  Yes the C# feature is apparently just a
 convenient way to create a value type with a special
 "none-of-the-above" value.
 I guess this feature is driven by need to connect with databases that
 often have nullable types.
 
 This chapter of a C# 2.0 book covering Nullable Types seems to agree
 with that assessment :
 http://www.springerlink.com/content/w2mh0571776t3114/



Not a very clever design. If they took a hit of a Boolean field (= a 
word field when padding is accounted for), they might as well have added 
a reference to Exception. That way, you not only know the value is null, 
you may also have info on why.

Andrei
Oct 20 2008
parent "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
Precisely. The solution they chose was adequate for the need at hand.

- Bent

"Denis Koroskin" <2korden gmail.com> skrev i meddelelsen 
news:op.ujds70e7o7cclz proton.creatstudio.intranet...

 On Tue, 21 Oct 2008 05:02:48 +0400, Bill Baxter <wbaxter gmail.com> wrote:


 On Tue, Oct 21, 2008 at 9:40 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Tue, Oct 21, 2008 at 9:11 AM, Lionello Lunesu 
 <lio lunesu.remove.com>
 wrote:

 Bent Rasmussen wrote:

 Not true. It wraps the value type in a struct with a boolean field
 expressing whether it is null or not.

 http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx



 Indeed. Thanks for pointing that out.

 So C#'s 'foo?' syntax has even less to do with this compile-time 
 nullness
 checking.



 Now it makes sense.  Yes the C# feature is apparently just a
 convenient way to create a value type with a special
 "none-of-the-above" value.
 I guess this feature is driven by need to connect with databases that
 often have nullable types.

 This chapter of a C# 2.0 book covering Nullable Types seems to agree
 with that assessment :
 http://www.springerlink.com/content/w2mh0571776t3114/



 Not a very clever design. If they took a hit of a Boolean field (= a 
 word
 field when padding is accounted for), they might as well have added a
 reference to Exception. That way, you not only know the value is null, 
 you
 may also have info on why.



 Hmm, I was thinking storing a pointer to the value itself would make
 more sense than a bool.
 Along these lines:

 struct Nullable(T)
 {
     private T _value;
     private T* _ptr;  // maybe points to _value, maybe null

     T* ptr { return _ptr; }
     T value() { return *_ptr; }
     void value(T v) { _value = v; _ptr = &_value; }
     void value(T* v) { if (v is null) { _ptr = null; } else { _value =
 *v; _ptr = &_value; } }
 }

 That way you just get a null pointer exception for free when you try
 to use the nulled value.
 But maybe that's not a workable approach in C#.

 --bb



 That's an overkill, operation cost gets too high for absolutely no reason.
Oct 21 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Tue, Oct 21, 2008 at 9:11 AM, Lionello Lunesu <lio lunesu.remove.com> wrote:

 Bent Rasmussen wrote:

 Not true. It wraps the value type in a struct with a boolean field
 expressing whether it is null or not.

 http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx



 Indeed. Thanks for pointing that out.

 So C#'s 'foo?' syntax has even less to do with this compile-time nullness
 checking.



Now it makes sense.  Yes the C# feature is apparently just a
convenient way to create a value type with a special
"none-of-the-above" value.
I guess this feature is driven by need to connect with databases that
often have nullable types.

This chapter of a C# 2.0 book covering Nullable Types seems to agree
with that assessment :
http://www.springerlink.com/content/w2mh0571776t3114/

--bb
Oct 20 2008
prev sibling next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Tue, Oct 21, 2008 at 9:35 AM, Bill Baxter <wbaxter gmail.com> wrote:

 On Tue, Oct 21, 2008 at 9:11 AM, Lionello Lunesu <lio lunesu.remove.com> wrote:

 Bent Rasmussen wrote:

 Not true. It wraps the value type in a struct with a boolean field
 expressing whether it is null or not.

 http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx



 Indeed. Thanks for pointing that out.

 So C#'s 'foo?' syntax has even less to do with this compile-time nullness
 checking.



 Now it makes sense.  Yes the C# feature is apparently just a
 convenient way to create a value type with a special
 "none-of-the-above" value.
 I guess this feature is driven by need to connect with databases that
 often have nullable types.

 This chapter of a C# 2.0 book covering Nullable Types seems to agree
 with that assessment :
 http://www.springerlink.com/content/w2mh0571776t3114/



Also C++ has *non*-Nullable types in the form of references.

void aFunction(ref Struct xyz) {
     // &xyz is a pointer that can't be null
}

ref Struct anotherFunction() {
    ...
}

&(anotherFunction()) --> can't be null

I think that may be a C++ FAQ  for "When do I use references vs
pointers?"  One answer to that is that if you don't want to allow
NULLs, use a reference.  If you do, then use a pointer.

--bb
Oct 20 2008
parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.176.1224549806.3087.digitalmars-d puremagic.com...

 On Tue, Oct 21, 2008 at 9:35 AM, Bill Baxter <wbaxter gmail.com> wrote:

 On Tue, Oct 21, 2008 at 9:11 AM, Lionello Lunesu <lio lunesu.remove.com> 
 wrote:

 Bent Rasmussen wrote:

 Not true. It wraps the value type in a struct with a boolean field
 expressing whether it is null or not.

 http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx



 Indeed. Thanks for pointing that out.

 So C#'s 'foo?' syntax has even less to do with this compile-time 
 nullness
 checking.



 Now it makes sense.  Yes the C# feature is apparently just a
 convenient way to create a value type with a special
 "none-of-the-above" value.
 I guess this feature is driven by need to connect with databases that
 often have nullable types.

 This chapter of a C# 2.0 book covering Nullable Types seems to agree
 with that assessment :
 http://www.springerlink.com/content/w2mh0571776t3114/



 Also C++ has *non*-Nullable types in the form of references.

 void aFunction(ref Struct xyz) {
     // &xyz is a pointer that can't be null
 }

 ref Struct anotherFunction() {
    ...
 }

 &(anotherFunction()) --> can't be null

 I think that may be a C++ FAQ  for "When do I use references vs
 pointers?"  One answer to that is that if you don't want to allow
 NULLs, use a reference.  If you do, then use a pointer.



But C++ references behave very differently from non-null-references. For 
one, you can't change what is being referenced.

L.
Oct 20 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Tue, Oct 21, 2008 at 9:40 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Tue, Oct 21, 2008 at 9:11 AM, Lionello Lunesu <lio lunesu.remove.com>
 wrote:

 Bent Rasmussen wrote:

 Not true. It wraps the value type in a struct with a boolean field
 expressing whether it is null or not.

 http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx



 Indeed. Thanks for pointing that out.

 So C#'s 'foo?' syntax has even less to do with this compile-time nullness
 checking.



 Now it makes sense.  Yes the C# feature is apparently just a
 convenient way to create a value type with a special
 "none-of-the-above" value.
 I guess this feature is driven by need to connect with databases that
 often have nullable types.

 This chapter of a C# 2.0 book covering Nullable Types seems to agree
 with that assessment :
 http://www.springerlink.com/content/w2mh0571776t3114/



 Not a very clever design. If they took a hit of a Boolean field (= a word
 field when padding is accounted for), they might as well have added a
 reference to Exception. That way, you not only know the value is null, you
 may also have info on why.



Hmm, I was thinking storing a pointer to the value itself would make
more sense than a bool.
Along these lines:

struct Nullable(T)
{
    private T _value;
    private T* _ptr;  // maybe points to _value, maybe null

    T* ptr { return _ptr; }
    T value() { return *_ptr; }
    void value(T v) { _value = v; _ptr = &_value; }
    void value(T* v) { if (v is null) { _ptr = null; } else { _value =
*v; _ptr = &_value; } }
}

That way you just get a null pointer exception for free when you try
to use the nulled value.
But maybe that's not a workable approach in C#.

--bb
Oct 20 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Tue, Oct 21, 2008 at 10:33 AM, Lionello Lunesu
<lionello lunesu.remove.com> wrote:

 "Bill Baxter" <wbaxter gmail.com> wrote in message
 news:mailman.176.1224549806.3087.digitalmars-d puremagic.com...

 On Tue, Oct 21, 2008 at 9:35 AM, Bill Baxter <wbaxter gmail.com> wrote:

 On Tue, Oct 21, 2008 at 9:11 AM, Lionello Lunesu <lio lunesu.remove.com>
 wrote:

 Bent Rasmussen wrote:

 Not true. It wraps the value type in a struct with a boolean field
 expressing whether it is null or not.

 http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx



 Indeed. Thanks for pointing that out.

 So C#'s 'foo?' syntax has even less to do with this compile-time
 nullness
 checking.



 Now it makes sense.  Yes the C# feature is apparently just a
 convenient way to create a value type with a special
 "none-of-the-above" value.
 I guess this feature is driven by need to connect with databases that
 often have nullable types.

 This chapter of a C# 2.0 book covering Nullable Types seems to agree
 with that assessment :
 http://www.springerlink.com/content/w2mh0571776t3114/



 Also C++ has *non*-Nullable types in the form of references.

 void aFunction(ref Struct xyz) {
    // &xyz is a pointer that can't be null
 }

 ref Struct anotherFunction() {
   ...
 }

 &(anotherFunction()) --> can't be null

 I think that may be a C++ FAQ  for "When do I use references vs
 pointers?"  One answer to that is that if you don't want to allow
 NULLs, use a reference.  If you do, then use a pointer.



 But C++ references behave very differently from non-null-references. For
 one, you can't change what is being referenced.



Yep, that's different.  As I understand it C++ disables rebinding just
because rebinding would require introducing a new "reference
assignment" operator to distinguish from plain a=b which operates on
the thing referred to not the reference itself.  And Bjarne thought
that would introduce too much complexity for too little benefit.  Most
of the time if you need to rebind a reference, you can just create a
new local variable for it.  My hunch is that covers about 90% of use
cases.

Anyway, maybe Bartosz will solve all our problems when part 2 of his
blog post comes out:
http://bartoszmilewski.wordpress.com/2008/10/18/who-ordered-rvalue-references-part-1/
;-)

--bb
Oct 20 2008
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 21 Oct 2008 05:02:48 +0400, Bill Baxter <wbaxter gmail.com> wrote:


 On Tue, Oct 21, 2008 at 9:40 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Tue, Oct 21, 2008 at 9:11 AM, Lionello Lunesu  
 <lio lunesu.remove.com>
 wrote:

 Bent Rasmussen wrote:

 Not true. It wraps the value type in a struct with a boolean field
 expressing whether it is null or not.

 http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx



 Indeed. Thanks for pointing that out.

 So C#'s 'foo?' syntax has even less to do with this compile-time  
 nullness
 checking.



 Now it makes sense.  Yes the C# feature is apparently just a
 convenient way to create a value type with a special
 "none-of-the-above" value.
 I guess this feature is driven by need to connect with databases that
 often have nullable types.

 This chapter of a C# 2.0 book covering Nullable Types seems to agree
 with that assessment :
 http://www.springerlink.com/content/w2mh0571776t3114/



 Not a very clever design. If they took a hit of a Boolean field (= a  
 word
 field when padding is accounted for), they might as well have added a
 reference to Exception. That way, you not only know the value is null,  
 you
 may also have info on why.



 Hmm, I was thinking storing a pointer to the value itself would make
 more sense than a bool.
 Along these lines:

 struct Nullable(T)
 {
     private T _value;
     private T* _ptr;  // maybe points to _value, maybe null

     T* ptr { return _ptr; }
     T value() { return *_ptr; }
     void value(T v) { _value = v; _ptr = &_value; }
     void value(T* v) { if (v is null) { _ptr = null; } else { _value =
 *v; _ptr = &_value; } }
 }

 That way you just get a null pointer exception for free when you try
 to use the nulled value.
 But maybe that's not a workable approach in C#.

 --bb



That's an overkill, operation cost gets too high for absolutely no reason.
Oct 21 2008
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 21 Oct 2008 04:43:18 +0400, Bill Baxter <wbaxter gmail.com> wrote:


 On Tue, Oct 21, 2008 at 9:35 AM, Bill Baxter <wbaxter gmail.com> wrote:

 On Tue, Oct 21, 2008 at 9:11 AM, Lionello Lunesu  
 <lio lunesu.remove.com> wrote:

 Bent Rasmussen wrote:

 Not true. It wraps the value type in a struct with a boolean field
 expressing whether it is null or not.

 http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx



 Indeed. Thanks for pointing that out.

 So C#'s 'foo?' syntax has even less to do with this compile-time  
 nullness
 checking.



 Now it makes sense.  Yes the C# feature is apparently just a
 convenient way to create a value type with a special
 "none-of-the-above" value.
 I guess this feature is driven by need to connect with databases that
 often have nullable types.

 This chapter of a C# 2.0 book covering Nullable Types seems to agree
 with that assessment :
 http://www.springerlink.com/content/w2mh0571776t3114/



 Also C++ has *non*-Nullable types in the form of references.

 void aFunction(ref Struct xyz) {
      // &xyz is a pointer that can't be null
 }

 ref Struct anotherFunction() {
     ...
 }

 &(anotherFunction()) --> can't be null

 I think that may be a C++ FAQ  for "When do I use references vs
 pointers?"  One answer to that is that if you don't want to allow
 NULLs, use a reference.  If you do, then use a pointer.

 --bb



That's not entirely true:

void foo(Bar& bar) { ... }

Bar* bar = NULL;
foo(*bar); // reference is NULL

In practice, however, I never got a NULL-reference passed.
Oct 21 2008
prev sibling next sibling parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Lionello Lunesu" <lionello lunesu.remove.com> wrote in message 
news:gdhd0f$g3v$1 digitalmars.com...
<snip>

 [1] http://delight.sourceforge.net/null.html



It seems that Delight had the same idea as Nice.  Which was first?

I see C# is a bit different - primitive types have nullable variants, but 
classes are always nullable.

Is there any language where you can have multiple levels of nullness? 
Something like Type?? which could represent, along with a Type object or 
lack thereof, a lack of any (Type object or lack thereof).  If that makes 
sense.  (It could be done with pointers in C/C++/D, but that adds levels of 
indirection and requires the programmer to allocate little bits of memory to 
deal with them.)


 [2] 
 http://research.microsoft.com/fsharp/manual/import-interop.aspx#Nullness



This might take a bit of studying to make sense of....

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Oct 20 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Stewart Gordon:

 It seems that Delight had the same idea as Nice.  Which was first?



Nice was first, of course.



 Is there any language where you can have multiple levels of nullness?



Cyclone has a quite refined (and it looks over-engineered) view of nullable
pointers and the like.
Boxes similar to nullable types are used often in Haskell, see the Maybe monad,
etc.

Bye,
bearophile
Oct 20 2008
prev sibling next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Mon, Oct 20, 2008 at 3:34 AM, Lionello Lunesu
<lionello lunesu.remove.com> wrote:

 Hi,

 I'm getting more and more intrigued by the way Delight [1] and F# [2] handle
 nullable types: using the type-system to check for "nullness" the way it
 does for constness*. I haven't used either one of those two languages, but
 since having read about both systems, I can't help keeping a tag in my mind
 for each variable; "this one can be null", "this one can't be null"...

 * Is there anybody with experience using this concept of nullness in F# or
 Delight?

 * Are there any other languages with this concept?

 * I personally think it would be nice for D too. Your opinions?



I just read up on Delight for the first time last night, and I didn't
know it was more than just a syntactic wrapper around D.  The maybe
types sound like something I'd really like to try out.
Oct 20 2008
prev sibling next sibling parent reply "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
Far more interesting that nullability of value types is non-nullability of 
reference types. The potential extinction of null-pointer exceptions. Spec# 
solves it, whether C# will solve it as well will be interesting to follow.

- Bent


"Lionello Lunesu" <lionello lunesu.remove.com> skrev i meddelelsen 
news:gdhd0f$g3v$1 digitalmars.com...

 Hi,

 I'm getting more and more intrigued by the way Delight [1] and F# [2] 
 handle nullable types: using the type-system to check for "nullness" the 
 way it does for constness*. I haven't used either one of those two 
 languages, but since having read about both systems, I can't help keeping 
 a tag in my mind for each variable; "this one can be null", "this one 
 can't be null"...

 * Is there anybody with experience using this concept of nullness in F# or 
 Delight?

 * Are there any other languages with this concept?

 * I personally think it would be nice for D too. Your opinions?

 L.

 PS. I have the feeling this also can be generalized, like the 
 green-code-red-code system. It's like a compile-time tagging of variables, 
 with some added syntactic sugar (the ?-token).

 [1] http://delight.sourceforge.net/null.html
 [2] 
 http://research.microsoft.com/fsharp/manual/import-interop.aspx#Nullness
Oct 20 2008
parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> wrote in message 
news:gdisrd$15a6$1 digitalmars.com...

 Far more interesting that nullability of value types is non-nullability of 
 reference types. The potential extinction of null-pointer exceptions. 
 Spec# solves it, whether C# will solve it as well will be interesting to 
 follow.



I agree. The constant wondering "what's null, what isn't" is driving me mad.

L.
Oct 20 2008
prev sibling parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Mon, 20 Oct 2008 08:34:30 +0100, Lionello Lunesu  
<lionello lunesu.remove.com> wrote:


 Hi,

 I'm getting more and more intrigued by the way Delight [1] and F# [2]  
 handle nullable types: using the type-system to check for "nullness" the  
 way it does for constness*. I haven't used either one of those two  
 languages, but since having read about both systems, I can't help  
 keeping a tag in my mind for each variable; "this one can be null",  
 "this one can't be null"...

 * Is there anybody with experience using this concept of nullness in F#  
 or Delight?

 * Are there any other languages with this concept?

 * I personally think it would be nice for D too. Your opinions?

 L.

 PS. I have the feeling this also can be generalized, like the  
 green-code-red-code system. It's like a compile-time tagging of  
 variables, with some added syntactic sugar (the ?-token).

 [1] http://delight.sourceforge.net/null.html
 [2]  
 http://research.microsoft.com/fsharp/manual/import-interop.aspx#Nullness



In C++ I've always used a very simply rule.
If it can possibly be null use a pointer.
If it should never be null use a reference.

In languages like Java where there is no such distinction life is  
difficult.
Of course you can still (I find its quite rare) have null references.
This indicates a programming error and is usually caused by the ground  
shifting
under your feet. For example append to a std::vector and it may need to be
re-allocated in order to accomodate it, which will invalidate any previous  
references.
This is another place where invariant would come in handy. A reference to  
an invariant
can never be invalidated.
I'm not sure how this pattern can be applied in D, as it seem to follow  
the Java mould
mixing the semantics of pointers and references. (disclaimer: I haven't  
been doing much D programming lately)

Regards,

Bruce.
Oct 25 2008