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). So you can be sure to have a valid well-defined object. But then there is always the ownership problem which renders them more dangerous as they seem to be. D resolves this problem using a garbage collector.

So why not combine the advantages of C++ references "always there" guarantee and D's garbage collector and make D's references not nullable? If you want it to be nullable, you can still make use of real pointers. Pointers can be converted to references by implicitly do a runtime check if the pointer is not null and references can be converted back to pointers.

I guess you had good reasons about choosing the nullable version of D references. Explain it to me, please.

On 15-09-2012 14:39, 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). So you can be sure to have a valid well-defined object. But
> then there is always the ownership problem which renders them more
> dangerous as they seem to be. D resolves this problem using a garbage
> collector.
>
> So why not combine the advantages of C++ references "always there"
> guarantee and D's garbage collector and make D's references not
> nullable? If you want it to be nullable, you can still make use of real
> pointers. Pointers can be converted to references by implicitly do a
> runtime check if the pointer is not null and references can be converted
> back to pointers.
>
> I guess you had good reasons about choosing the nullable version of D
> references. Explain it to me, please.

D references are not like C++ references *at all*. Reference types in D are always classes - no exceptions. When you just need to pass something by reference down the call stack and be sure you have no null references, you can use 'ref'.

But this being said, I agree that references being nullable by default is hurtful. It allows any object reference to have an invalid state even though in 99% of cases, that doesn't make sense. It's a giant hole in the type system that many new languages have gotten rid of very early (forcing the programmer to use explicit option/nullable types).

The way references work in D is pretty much inherited from Java/C#.

http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare

Anyway, it's too late to change it now.

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

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.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

That is the one thing I miss also.
The solution until now is to use a wrapper struct around a class, but that is _very_ annoying and a good language should have something on their own.

But it is right, for D2 this mistake is going to long as you can change it so soon.
But maybe a Syntax like in C++ could help: If you want a not nullable reference use &: void foo(Foo& f) { and if you want a nullable Reference do nothing extra.
I still work on a (pre)compiler that converts statements like Foo& f into Ref!Foo but I think D should do this on their own.

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.

The best way to stay tuned for that change is to always pray references to be valid, thus to do no explicit runtime checks.

Are you using reference runtime checks in your current code?

On Saturday, 15 September 2012 at 12:38:53 UTC, 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). So you can be sure to have a valid well-defined object. But then there is always the ownership problem which renders them more dangerous as they seem to be. D resolves this problem using a garbage collector.
>
> So why not combine the advantages of C++ references "always there" guarantee and D's garbage collector and make D's references not nullable? If you want it to be nullable, you can still make use of real pointers. Pointers can be converted to references by implicitly do a runtime check if the pointer is not null and references can be converted back to pointers.
>
> I guess you had good reasons about choosing the nullable version of D references. Explain it to me, please.

Completely disagree. By the way, you are mixing references and classes.
struct S {}

void foo(ref S s); // cannot pass null pointer S* or null - "always there"

On Saturday, 15 September 2012 at 12:43:22 UTC, Alex Rønne Petersen wrote:
> But this being said, I agree that references being nullable by default is hurtful. It allows any object reference to have an invalid state even though in 99% of cases, that doesn't make sense. It's a giant hole in the type system that many new languages have gotten rid of very early (forcing the programmer to use explicit option/nullable types).

Are speaking about classes? Then how they can be initialized (except for null and other existing object)?

On Sat, 15 Sep 2012 15:32:35 +0200, Maxim Fomin <maxim@maxim-fomin.ru> wrote:

> On Saturday, 15 September 2012 at 12:38:53 UTC, 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). So you can be sure to have a valid well-defined object. But then there is always the ownership problem which renders them more dangerous as they seem to be. D resolves this problem using a garbage collector.
>>
>> So why not combine the advantages of C++ references "always there" guarantee and D's garbage collector and make D's references not nullable? If you want it to be nullable, you can still make use of real pointers. Pointers can be converted to references by implicitly do a runtime check if the pointer is not null and references can be converted back to pointers.
>>
>> I guess you had good reasons about choosing the nullable version of D references. Explain it to me, please.
>
> Completely disagree. By the way, you are mixing references and classes.
> struct S {}
>
> void foo(ref S s); // cannot pass null pointer S* or null - "always there"

void bar( ref int n ) {
    n = 3;
}

void main( ) {
    int* p = null;
    bar( *p );
}

Good luck.

Of course, it's not that obvious in production code, but I've had this
happen to me in C++, and - obviously - it can happen in D, too.

-- 
Simen

On Saturday, 15 September 2012 at 13:36:00 UTC, Maxim Fomin wrote:
> On Saturday, 15 September 2012 at 12:43:22 UTC, Alex Rønne Petersen wrote:
>> But this being said, I agree that references being nullable by default is hurtful. It allows any object reference to have an invalid state even though in 99% of cases, that doesn't make sense. It's a giant hole in the type system that many new languages have gotten rid of very early (forcing the programmer to use explicit option/nullable types).
>
> Are speaking about classes? Then how they can be initialized (except for null and other existing object)?

When you want it to be initialized with null, use a pointer. Else you can use something like this:

class AClass {
	this(BClass bclass = new BClass) {
		_class = bclass;
	}
	
	BClass _class;	
}

By the way, a pointer holds two pieces information:
1) If there is an object available
2) If so, the object itself

In most cases, you only need the second one and the if is redunant.

On Saturday, 15 September 2012 at 13:49:02 UTC, Simen Kjaeraas wrote:
>> void foo(ref S s); // cannot pass null pointer S* or null - "always there"
>
> void bar( ref int n ) {
>     n = 3;
> }
>
> void main( ) {
>     int* p = null;
>     bar( *p );
> }
>
> Good luck.
>
> Of course, it's not that obvious in production code, but I've had this
> happen to me in C++, and - obviously - it can happen in D, too.

The problem happens because you deliberately passed hidden null pointer. And in real code it could crash after dereferencing and before passing to bar, if accessed (meaning that problem is in erroneous pointer usage, not accepting ints through reference in bar). Certainly, it is possible to break even in such cases, as well as in other parts of the language which doesn't necessarily mean that such parts of the language are broken. What I was talking about is:

void bar( ref int n ) {
    n = 3;
}

void main( ) {
    int* p = null;
    bar(p); // error
    bar(null); //error
}