On 16-09-2012 13:33, Jacob Carlborg wrote:
> On 2012-09-15 23:30, Walter Bright wrote:
>
>> Doing null references in C++ is simple:
>>
>> int *p = NULL;
>> int& r = *p;
>>
>> r = 3; // crash
>
> Won't that crash at the first assignment of "r", since you dereferencing
> a null pointer?.
>

Nope, since in this context you're assigning it to an int&. So it really just means "r = p" if you assume that references are just pointers (which they are in most implementations).

D works like this too, if you pass a *p to a ref parameter and such.

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

On 2012-09-16 13:47, Alex Rønne Petersen wrote:

> Nope, since in this context you're assigning it to an int&. So it really
> just means "r = p" if you assume that references are just pointers
> (which they are in most implementations).

Ah, I didn't think of that.

-- 
/Jacob Carlborg

Le 15/09/2012 16:23, Alex Rønne Petersen a écrit :
> On 15-09-2012 15:24, 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.
>>
>> 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?
>
> D has null references, so I use them. I would prefer option types, but
> they are too verbose in D as things stand.
>

It shouldn't be that hard to create a Nullable!T template.

Le 15/09/2012 19:13, Jonathan M Davis a écrit :
> 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

Years of java have proven me the exact opposite. Nullable is a usefull construct, but nullable by default is on the wrong side of the force.

On Sunday, September 16, 2012 12:08:52 Peter Alexander wrote:
> My favourite C++ wtf:
> 
> struct Foo
> {
>      template <int x, int y> int fun(bool c) { return c ? x : y; }
> };
> 
> struct Bar
> {
>      int fun;
> };
> 
> template <typename T>
> int madness()
> {
>      return T().fun<1, 2>(true);
> }
> 
> The WTF: madness<Foo> doesn't compile, but madness<Bar> does
> (with a warning).

Ouch. I assume that that's due to the two-pass template lookup nonsense (or whatever the exact name is), which means that that probably won't even behave the same across compilers, since not all compilers implement that the same way (most notably, Microsoft specifically echoues it in favor of a scheme that makes more sense, though it's still a bad idea, since it's non-standard). Thank goodness that D didn't follow C++'s example on _that_ one.

- Jonathan M Davis

On Monday, September 17, 2012 00:43:50 deadalnix wrote:
> It shouldn't be that hard to create a Nullable!T template.

We have one, and it would be wasteful to use that for references or pointers when they're naturally nullable (though you're more or less forced to if you want a truly nullable array thanks to the nonsense that empty arrays and null arrays are considered equal). You're forced to have a separate boolean value indicating whether it's null or not. That might make sense for an int, since it can't be null, but pointers and references _can_ be and are in every type system that I've ever used.

Regardless, the solution at this point is going to be to add std.typecons.NonNullable. It would be in there already, but the pull request with it needed more work, and it hasn't been resubmitted yet.

- Jonathan M Davis

On 09/17/2012 02:23 AM, Jonathan M Davis wrote:
> ...  That might make sense for an int, since
> it can't be null, but pointers and references _can_ be and are in every type
> system that I've ever used.
>...

You have claimed multiple times to have used Haskell.

On Monday, September 17, 2012 03:27:10 Timon Gehr wrote:
> On 09/17/2012 02:23 AM, Jonathan M Davis wrote:
> > ...  That might make sense for an int, since
> > it can't be null, but pointers and references _can_ be and are in every
> > type system that I've ever used.
> >
> >...
> 
> You have claimed multiple times to have used Haskell.

I have, but I've never used pointers in haskell, so if they're non-nullable, I wouldn't know about it. I believe that everything in Haskell is an immutable value type as far as what I've dealt with goes.

- Jonathan M Davis

On Monday, 17 September 2012 at 00:22:52 UTC, Jonathan M Davis wrote:
> On Monday, September 17, 2012 00:43:50 deadalnix wrote:
>> It shouldn't be that hard to create a Nullable!T template.
>
> We have one, and it would be wasteful to use that for references or pointers
> when they're naturally nullable (though you're more or less forced to if you
> want a truly nullable array thanks to the nonsense that empty arrays and null
> arrays are considered equal). You're forced to have a separate boolean value
> indicating whether it's null or not. That might make sense for an int, since
> it can't be null, but pointers and references _can_ be and are in every type
> system that I've ever used.
>
> Regardless, the solution at this point is going to be to add
> std.typecons.NonNullable. It would be in there already, but the pull request
> with it needed more work, and it hasn't been resubmitted yet.
>
> - Jonathan M Davis

Instead of "NonNullable" a built-in operator would be preferable. Because it seems as though many would like to have something.

Short example:

void foo(Foo& f) { }
void main() {
    Foo& f1; // <-- error, not-null references declared, but not assigned.
    Foo f2; // <-- ok

    foo(f1); // <-- we can trust, f1 has a valid value
    foo(f2); /* we cannot trust, the compiler checks at runtime, if f2 has a valid value.*/

Le 17/09/2012 02:23, Jonathan M Davis a écrit :
> On Monday, September 17, 2012 00:43:50 deadalnix wrote:
>> It shouldn't be that hard to create a Nullable!T template.
>
> We have one, and it would be wasteful to use that for references or pointers
> when they're naturally nullable (though you're more or less forced to if you
> want a truly nullable array thanks to the nonsense that empty arrays and null
> arrays are considered equal). You're forced to have a separate boolean value
> indicating whether it's null or not. That might make sense for an int, since
> it can't be null, but pointers and references _can_ be and are in every type
> system that I've ever used.
>

And this have proven to be an important source of problem in mostly all languages.

> Regardless, the solution at this point is going to be to add
> std.typecons.NonNullable. It would be in there already, but the pull request
> with it needed more work, and it hasn't been resubmitted yet.
>

I don't think this is implementable as a lib in a satisfying way.