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

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.

Andrei

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

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

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

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

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

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

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

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.