On Saturday, September 15, 2012 19:35:44 Alex Rønne Petersen wrote:
> Out of curiosity: Why? How often does your code actually accept null as a valid state of a class reference?

I have no idea. I know that it's a non-negligible amount of the time, though it's certainly true that they normally have values. But null is how you indicate that a reference has no value. The same goes for arrays and pointers. Sometimes it's useful to have null and sometimes it's useful to know that a value can't be null. I confess though that I find it very surprising how much some people push for non-nullable references, since I've never really found null to be a problem. Sure, once in a while, you get a null pointer/reference and something blows up, but that's very rare in my experience, so I can't help but think that people who hit issues with null pointers on a regular basis are doing something wrong.

- Jonathan M Davis

On Saturday, 15 September 2012 at 17:12:23 UTC, Jonathan M Davis wrote:
> Of course people use it. Having nullable types is _highly_ useful. It would
> suck if references were non-nullable. That would be _horrible_ IMHO. Having a
> means to have non-nullable references for cases where that makes sense isn't
> necessarily a bad thing, but null is a very useful construct, and I'd _hate_
> to see normal class references be non-nullable.
>
> - Jonathan M Davis

And many usages of null as a state leads to really bad design. There are functions which behaviour is completly different if you pass null instead of a valid pointer/reference. An example would be:

http://www.khronos.org/registry/cl/sdk/1.1/docs/man/xhtml/clGetDeviceIDs.html

On Saturday, September 15, 2012 19:57:03 Henning Pohl wrote:
> On Saturday, 15 September 2012 at 17:12:23 UTC, Jonathan M Davis
> 
> wrote:
> > Of course people use it. Having nullable types is _highly_
> > useful. It would
> > suck if references were non-nullable. That would be _horrible_
> > IMHO. Having a
> > means to have non-nullable references for cases where that
> > makes sense isn't
> > necessarily a bad thing, but null is a very useful construct,
> > and I'd _hate_
> > to see normal class references be non-nullable.
> > 
> > - Jonathan M Davis
> 
> And many usages of null as a state leads to really bad design. There are functions which behaviour is completly different if you pass null instead of a valid pointer/reference. An example would be:
> 
> http://www.khronos.org/registry/cl/sdk/1.1/docs/man/xhtml/clGetDeviceIDs.htm l

I'd argue that using null for indicating something other than the lack of a value is bad design. But there are plenty of cases where being able to indicate that there is no value is useful. And if a function requires that a pointer or reference or array or whatever have a value, then there's always DbC or exceptions. Just because someone can misuse a feature doesn't mean that a feature shouldn't be there.

- Jonathan M Davis

On Saturday, 15 September 2012 at 18:05:55 UTC, Jonathan M Davis wrote:
> I'd argue that using null for indicating something other than the lack of a
> value is bad design. But there are plenty of cases where being able to
> indicate that there is no value is useful.
I agree.

> And if a function requires that a
> pointer or reference or array or whatever have a value, then there's always
> DbC or exceptions.
So why not clear this up at compile time if possible? Then you can also easily distinguish between "really there" and "maybe there" objects by passing either a reference or a pointer.

> Just because someone can misuse a feature  doesn't mean that
> a feature shouldn't be there.
Why not set the "non-nullable references", which cannot be misused, as default and still enable the "nullable references" feature as optional by passing a pointer.

On Saturday, September 15, 2012 20:24:52 Henning Pohl wrote:
> On Saturday, 15 September 2012 at 18:05:55 UTC, Jonathan M Davis
> 
> wrote:
> > I'd argue that using null for indicating something other than
> > the lack of a
> > value is bad design. But there are plenty of cases where being
> > able to
> > indicate that there is no value is useful.
> 
> I agree.
> 
> > And if a function requires that a
> > pointer or reference or array or whatever have a value, then
> > there's always
> > DbC or exceptions.
> 
> So why not clear this up at compile time if possible? Then you can also easily distinguish between "really there" and "maybe there" objects by passing either a reference or a pointer.
> 
> > Just because someone can misuse a feature  doesn't mean that a feature shouldn't be there.
> 
> Why not set the "non-nullable references", which cannot be misused, as default and still enable the "nullable references" feature as optional by passing a pointer.

You can't have pointers to class objects in D. You can have pointers to references but not to the objects that they point to, because the type system does not have the concept of a class object separate from a reference. And such pointers are non-polymorphic to boot. So, it doesn't make any sense at all to try and pass around pointers to classes as a solution for much of anythnig.

Regardless, at this point, D has nullable references, and that's not going to change. It's far too late for that. Non-nullable references could be added at some point in the future, but at this point, Walter and Andrei both think that having a NonNullable struct in the standard library which wraps a reference and asserts that it's non-null is good enough and that changing the language isn't worth it, especially since we're trying to fully stabilize the language and not be adding features unless we really need them and they can't reasonably be done in the library. And while it may not be quite as good as having non-nullable references in the language, you _can_ create a library solution for them, and such a solution is going to be added to the standard library.

It may be that if/when D3 materializes that non-nullable references will be added to the language, but that's years off at this point.

- Jonathan M Davis

On 15-09-2012 19:52, Jonathan M Davis wrote:
> On Saturday, September 15, 2012 19:35:44 Alex Rønne Petersen wrote:
>> Out of curiosity: Why? How often does your code actually accept null as
>> a valid state of a class reference?
>
> I have no idea. I know that it's a non-negligible amount of the time, though
> it's certainly true that they normally have values. But null is how you
> indicate that a reference has no value. The same goes for arrays and pointers.
> Sometimes it's useful to have null and sometimes it's useful to know that a
> value can't be null. I confess though that I find it very surprising how much
> some people push for non-nullable references, since I've never really found
> null to be a problem. Sure, once in a while, you get a null pointer/reference
> and something blows up, but that's very rare in my experience, so I can't help
> but think that people who hit issues with null pointers on a regular basis are
> doing something wrong.
>
> - Jonathan M Davis
>

People are humans. Humans make mistakes. In D, you can trivially get null references because references and pointers are default-initialized to null.

Anyway, in a type system where there is no nullability on types by default, you can simply say that the tail type constructor '?' indicates nullability. So, for example:

int* = pointer to int
int*? = nullable pointer to int
Foo = reference to Foo
Foo? = nullable reference to Foo
int[] = array of int
int[]? = nullable array of int

and so on. It's fairly trivial to set up a sane type system this way, and you make it explicit where null is acceptable. This is how type systems should be done IMO - things should not be allowed to have some arbitrary invalid state unless the programmer allows it.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

Alex Rønne Petersen:

> and so on. It's fairly trivial to set up a sane type system this way, and you make it explicit where null is acceptable. This is how type systems should be done IMO - things should not be allowed to have some arbitrary invalid state unless the programmer allows it.

I agree, but creation, initialization and interactions between objects is not trivial when you introduce nonnullables. This complexity is a cost that must be taken into account.

Bye,
bearophile

On Sat, 15 Sep 2012 10:52:19 -0700
Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> 
> once in a while, you get a null pointer/reference and something blows up, but that's very rare in my experience, so I can't help but think that people who hit issues with null pointers on a regular basis are doing something wrong.
> 

I don't think it's just people having trouble with null references. If you're not getting null reference issues, then you're almost certainly doing at least some work making sure to manually check for and handle nulls when needed. That's effort that could be better directed elsewhere.

On 09/15/2012 07:13 PM, Jonathan M Davis wrote:
> On Saturday, September 15, 2012 15:24:27 Henning Pohl wrote:
>> On Saturday, 15 September 2012 at 12:49:23 UTC, Russel Winder
>>
>> wrote:
>>> On Sat, 2012-09-15 at 14:44 +0200, Alex Rønne Petersen wrote:
>>> […]
>>>
>>>> Anyway, it's too late to change it now.
>>>
>>> I disagree. There are always opportunities to make changes to
>>> things,
>>> you just have manage things carefully.
>>
>> I don't know if people really use the ability of references being
>> null. If so, large amounts of code will be broken.
>
> Of course people use it. Having nullable types is _highly_ useful. It would
> suck if references were non-nullable. That would be _horrible_ IMHO. Having a
> means to have non-nullable references for cases where that makes sense isn't
> necessarily a bad thing, but null is a very useful construct, and I'd _hate_
> to see normal class references be non-nullable.
>
> - Jonathan M Davis
>

In a sane type system, optionality is a concept separate from a
reference and it is much more general.

On 9/15/2012 5:39 AM, Henning Pohl wrote:
> The way D is dealing with classes reminds me of pointers because you can null
> them. C++'s references cannot (of course you can do some nasty casting).

Doing null references in C++ is simple:

int *p = NULL;
int& r = *p;

r = 3; // crash