On Wednesday, 3 October 2012 at 08:11:32 UTC, Franciszek Czekała wrote:
> On Saturday, 15 September 2012 at 17:12:23 UTC, 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
>
> Agreed. Nullable types are a feature not a bug. There is no need to change it. Bugs occur when you do not know the language rules and make assumptions instead. This can happen whith any language and any rules. As to an example use of nullable references: consider a board game (for example chess). The boards has cells which can be empty or occupied. Model this with an array of class objects  representing pieces. null reference means a cell is not occupied. If you want to remove a piece from the board assign null to it and GC will take care of the rest. Now, doing this with full objects representing empty cells would require needless work to define such "null" objects and would be wasteful of memory (typically boards are sparsely populated). Now imagine a really big board and every cell holding references to useless objects simulating null references. It would not make sense. Saying that null references are evil is just propaganda. Let's keep D a sane language.

Regarding my example: we could probably do with a single "null" object stored in all empty cells, but still this would be an unnecessary complication.

On Wednesday, 3 October 2012 at 08:11:32 UTC, Franciszek Czekała wrote:
> Agreed. Nullable types are a feature not a bug. There is no need to change it. Bugs occur when you do not know the language rules and make assumptions instead. This can happen whith any language and any rules. As to an example use of nullable references: consider a board game (for example chess). The boards has cells which can be empty or occupied. Model this with an array of class objects  representing pieces. null reference means a cell is not occupied. If you want to remove a piece from the board assign null to it and GC will take care of the rest. Now, doing this with full objects representing empty cells would require needless work to define such "null" objects and would be wasteful of memory (typically boards are sparsely populated). Now imagine a really big board and every cell holding references to useless objects simulating null references. It would not make sense. Saying that null references are evil is just propaganda. Let's keep D a sane language.

There is a related question at stackoverflow: http://stackoverflow.com/questions/693325/non-nullable-reference-types

As you can see the "nullable references are great" guy has been voted down.

I've written like 5k lines of code in D and never felt the need of using null. C++'s std::shared_ptr has the same issue, but at least it is called pointer.

On Wednesday, 3 October 2012 at 10:41:34 UTC, Henning Pohl wrote:
> On Wednesday, 3 October 2012 at 08:11:32 UTC, Franciszek Czekała wrote:
>> Agreed. Nullable types are a feature not a bug. There is no need to change it. Bugs occur when you do not know the language rules and make assumptions instead. This can happen whith any language and any rules. As to an example use of nullable references: consider a board game (for example chess). The boards has cells which can be empty or occupied. Model this with an array of class objects  representing pieces. null reference means a cell is not occupied. If you want to remove a piece from the board assign null to it and GC will take care of the rest. Now, doing this with full objects representing empty cells would require needless work to define such "null" objects and would be wasteful of memory (typically boards are sparsely populated). Now imagine a really big board and every cell holding references to useless objects simulating null references. It would not make sense. Saying that null references are evil is just propaganda. Let's keep D a sane language.
>
> There is a related question at stackoverflow: http://stackoverflow.com/questions/693325/non-nullable-reference-types
>
> As you can see the "nullable references are great" guy has been voted down.
>
> I've written like 5k lines of code in D and never felt the need of using null. C++'s std::shared_ptr has the same issue, but at least it is called pointer.

Since when stackoverflow comment reputation is a word in a programming languages? Especially, in issue which is subject for human desire to escape from awareness and then complaining about arised problems.

On Wednesday, 3 October 2012 at 10:41:34 UTC, Henning Pohl wrote:
> On Wednesday, 3 October 2012 at 08:11:32 UTC, Franciszek Czekała wrote:
>> Agreed. Nullable types are a feature not a bug. There is no need to change it. Bugs occur when you do not know the language rules and make assumptions instead. This can happen whith any language and any rules. As to an example use of nullable references: consider a board game (for example chess). The boards has cells which can be empty or occupied. Model this with an array of class objects  representing pieces. null reference means a cell is not occupied. If you want to remove a piece from the board assign null to it and GC will take care of the rest. Now, doing this with full objects representing empty cells would require needless work to define such "null" objects and would be wasteful of memory (typically boards are sparsely populated). Now imagine a really big board and every cell holding references to useless objects simulating null references. It would not make sense. Saying that null references are evil is just propaganda. Let's keep D a sane language.
>
> There is a related question at stackoverflow: http://stackoverflow.com/questions/693325/non-nullable-reference-types
>
> As you can see the "nullable references are great" guy has been voted down.
>
> I've written like 5k lines of code in D and never felt the need of using null. C++'s std::shared_ptr has the same issue, but at least it is called pointer.

The need of using null: Every type needs a default value. null supplies it perfectly for all class types in D. And it makes sense regardless of what stackoverflow self-appointed political commisars want you to believe. Consider my board example: with null standing for "empty cell" when a new board is created as an array it is by default empty -> in a meaningful state (think of games like Go, etc). And at any rate you are going to use a property/function like IsEmpty to check for empty cells. Why should it be a problem to implement it by comparing with null? If anything, it has a chance of being faster than when some other concrete reference is used. Without null references you will end up defining "null" objects all over the place (and sometimes it may just be impossible when all values are meaningful). Then you will have to store them globally and compare everything with these objects (named like NullBoard, NullPiece, NullPawn, etc, etc because it is ah so much better than just using a single keyword null) and if you forget your program will silently churn out garbage. With plain null references at least you would get an exception. I'd rather see an exception than have a program running smoothly with nonsensical results. Like seeing pieces vanishing because they are being captured with a "null" piece which I forgot to test for being "null". Because, you know, you will still have to test conditions in your program to make it meaningful, except that it may be a lot more troublesome when your program grows x2 in size because of all those "safety" mechanisms.

On 2012-56-03 14:10,  wrote:

> The need of using null: Every type needs a default value.

Good gods, are we not done with this strawman yet?

No, not all types need a default value. In fact, for some types, it is
much better that they don't.


> Consider my board example: with null standing for "empty cell" when a new board is created as an array it is by default empty -> in a meaningful state (think of games like Go, etc).

Yes, null is useful. Nobody is trying to take null away from you.

What we want is the ability to say 'this can never be null', so that we
don't need to check for null over and over.


> And at any rate you are going to use a property/function like IsEmpty to check for empty cells. Why should it be a problem to implement it by comparing with null?

This is not what non-nullable references are about.

When not to use non-nullable references:
 - When the absence of a value is a valid value.
Example:
 - Chess board boxes.

When to use non-nullable references:
 - When the absence of a value is not a valid value.
Example:
 - RenderFoo(NotNull!Foo)


> Without null references you will end up defining "null" objects all over the place (and sometimes it may just be impossible when all values are meaningful).

No. Please read more about non-nullable references.


> Then you will have to store them globally and compare everything with these objects (named like NullBoard, NullPiece, NullPawn, etc, etc because it is ah so much better than just using a single keyword null) and if you forget your program will silently churn out garbage. With plain null references at least you would get an exception. I'd rather see an exception than have a program running smoothly with nonsensical results. Like seeing pieces vanishing because they are being captured with a "null" piece which I forgot to test for being "null". Because, you know, you will still have to test conditions in your program to make it meaningful, except that it may be a lot more troublesome when your program grows x2 in size because of all those "safety" mechanisms.

This... Please... Please, just read more about the topic before
commenting. Please.

-- 
Simen

On Wednesday, 3 October 2012 at 14:49:36 UTC, Simen Kjaeraas wrote:
> On 2012-56-03 14:10,  wrote:
>
>> The need of using null: Every type needs a default value.
>
> Good gods, are we not done with this strawman yet?
>
> No, not all types need a default value. In fact, for some types, it is
> much better that they don't.
>
>
>> Consider my board example: with null standing for "empty cell" when a new board is created as an array it is by default empty -> in a meaningful state (think of games like Go, etc).
>
> Yes, null is useful. Nobody is trying to take null away from you.
>
> What we want is the ability to say 'this can never be null', so that we
> don't need to check for null over and over.
>
>
>> And at any rate you are going to use a property/function like IsEmpty to check for empty cells. Why should it be a problem to implement it by comparing with null?
>
> This is not what non-nullable references are about.
>
> When not to use non-nullable references:
>  - When the absence of a value is a valid value.
> Example:
>  - Chess board boxes.
>
> When to use non-nullable references:
>  - When the absence of a value is not a valid value.
> Example:
>  - RenderFoo(NotNull!Foo)
>
>
>> Without null references you will end up defining "null" objects all over the place (and sometimes it may just be impossible when all values are meaningful).
>
> No. Please read more about non-nullable references.
>
>
>> Then you will have to store them globally and compare everything with these objects (named like NullBoard, NullPiece, NullPawn, etc, etc because it is ah so much better than just using a single keyword null) and if you forget your program will silently churn out garbage. With plain null references at least you would get an exception. I'd rather see an exception than have a program running smoothly with nonsensical results. Like seeing pieces vanishing because they are being captured with a "null" piece which I forgot to test for being "null". Because, you know, you will still have to test conditions in your program to make it meaningful, except that it may be a lot more troublesome when your program grows x2 in size because of all those "safety" mechanisms.
>
> This... Please... Please, just read more about the topic before
> commenting. Please.

> When to use non-nullable references:
>  - When the absence of a value is not a valid value.

As my comments indicated : the presence of a value does not guarantee a valid value by itself. The C++ declaration int n; introduces a value, good luck using it. In short, having null references is useful (a value outside of the type cannot be introduced easily unless the language gives a hand, check eof() in C++ character_traits), while forcing non-null references hardly offers any significant advantage. Not enough to justify complicating the syntax of the language to have it both ways.

On Wednesday, 3 October 2012 at 12:56:41 UTC, Franciszek Czekała wrote:
> The need of using null: Every type needs a default value.

This is just plain wrong. There even is a feature in D which solely exists for the purpose of allowing struct types _not_ to have a default value (@disable this)…

David

On 2012-10-03, 18:12,  wrote:

> As my comments indicated : the presence of a value does not guarantee a valid value by itself. The C++ declaration int n; introduces a value, good luck using it.

Which is why non-nullable references must not allow the programmer to
declare them without also assigning a valid value (hence the no default
value [note that this is completely different from 'random default value',
which is what you indicate above]). This is easily checkable in a
constructor.


> In short, having null references is useful (a value outside of the type cannot be introduced easily unless the language gives a hand, check eof() in C++ character_traits),

Good gripes, I thought we'd been through this. If you need null, use
it, already! Nobody is trying to take it away, we're suggesting that
most uses of pointers/references should never be null, and such a
constraint can and should be modeled in the type system.

It's also worth pointing out that others have invented (non-null)
sentinel values even for nullable types.


> while forcing non-null references hardly offers any significant
> advantage.

They make sure you never pass null to a function that doesn't expect
null - I'd say that's a nice advantage.

As you may well be aware, reals are supersets of longs, just like
nullable references are supersets of non-nullable references. If
the argument was that (performance aside) you should simply use
real wherever a long was needed, would you consider that a good idea?
I mean, it's just a matter of making sure you never store a NaN or
other non-integer in it.

The example is admittedly more extreme, but the general idea is the
same.

-- 
Simen

On Wednesday, 3 October 2012 at 16:11:53 UTC, Franciszek Czekała wrote:
> As my comments indicated : the presence of a value does not
> guarantee a valid value by itself. The C++ declaration int n; introduces a value, good luck using it.
auto c = new Class();

Tell me, does c contain an invalid value now?

> In short, having null references is useful (a value outside of the type cannot be introduced easily unless the language gives a hand, check eof() in C++ character_traits),
Null references are useful, that's right. Nobody wants to take them away. Just put something like a questionmark behind the reference type to indicate that it's nullable.

> while forcing non-null references hardly offers any significant advantage.
1) Performance, no or very few null-checks.
2) Code is shorter, looks better, less duplications.
3) Clarity. User of functions know, whether a function can return null at compile time.

> Not enough to justify complicating the syntax of the language to have it both ways.
Not really. It's all about one question mark for example.

On Wednesday, 3 October 2012 at 16:36:15 UTC, Henning Pohl wrote:
> Just put something like a questionmark behind the reference type to indicate that it's nullable.
...
> Not really. It's all about one question mark for example.

How much code would be broken by moving nullable references from current state to "question mark notation"?

I expect that non-nullable class objects (called references here) addition (if there is no objections to idea in general) would not break much code and would not request vast syntax changes. And it likely can be done by still defaulting to nullable references. For example, it can be done with the help of @nonnullable (like immutable) type qualifier and semantic check of operations involving references with such qualifier. Anyway, my estimation of probability of accepting constructions like "type&", "type*?", etc and defaulting to non-null references is very low, at least for D2.