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.

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.

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. 

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.