The very good Mark C. Chu-Carroll has written a little blog post about the lack of null-related errors in his Scala code:

http://scientopia.org/blogs/goodmath/2012/08/20/nulls/

Bye,
bearophile

On Tue, 21 Aug 2012 12:32:31 +0100, bearophile <bearophileHUGS@lycos.com> wrote:

> The very good Mark C. Chu-Carroll has written a little blog post about the lack of null-related errors in his Scala code:
>
> http://scientopia.org/blogs/goodmath/2012/08/20/nulls/

This article links to:
http://beust.com/weblog/2012/08/19/a-note-on-null-pointers/

very early on.  Which is also a good read, and has parallels with the NaN discussion as well :p

I really like the Groovy/Fantom/Kotlin syntax shown:

[quote]
For example, here is how Kotlin lets you ignore null values encountered along a chain of invocations:

  bob?.department?.head?.name

If either of these accesses returns null, the result of this expression will be null. No need to put your values into monadic boxes nor mapping through them, just use the standard composition operator you are familiar with if you are using a C family language.
[/quote]

I think this would be a neat D feature.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Tue, 21 Aug 2012 12:32:31 +0100, bearophile <bearophileHUGS@lycos.com> wrote:

> The very good Mark C. Chu-Carroll has written a little blog post about the lack of null-related errors in his Scala code:
>
> http://scientopia.org/blogs/goodmath/2012/08/20/nulls/

It's prob no obvious from my other reply, but you might have guessed, I'm of the opinion that Otaku, Cedric's blog post is spot on and Mark C is wrong.  Well, not wrong exactly but not right either.

A Null pointer exception in Java will give you a stack trace, meaning you can be sure which method triggered it, meaning you don't have to examine "everything", just those method calls/objects used therein.

If your method is so large that this is a daunting task, then you're already doing something wrong.

Plus, I don't buy the argument that having to explicitly type ".get" will stop anyone from automatically coding statements like:

val g: Option[T] = f.doSomething()
g.get.doSomethingElse()

and suffering the exact same null pointer exception/error despite using Option and boxing into a Not-Null type.

Like checked exceptions people will simply ignore the possibility of error and type the above anyway.  So, end result, it's just more typing for no real gain.

On the other hand, the suggested syntax of "bob?.department?.head?.name" from Kotlin is pure genius, and has a good chance of actually being used.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Tue, 21 Aug 2012 13:55:58 +0200, Regan Heath <regan@netmail.co.nz> wrote:

> I don't buy the argument that having to explicitly type ".get" will stop anyone from automatically coding statements like:
>
> val g: Option[T] = f.doSomething()
> g.get.doSomethingElse()

So don't give them that access?

I have an Option struct on my home computer that only allows access to
the held value if the error case is simultaneously handled:

Option!int a = foo();

int n = a.match!(
    (int x) => x,
    (None n) => 0 // or throw, or what have you.
    );

The same solution is perfectly adaptable to MaybeNull, MaybeNan, and probably
a host of others of the same family.

With some clever use of opDispatch, one could write an Option struct that
lets you call methods and acces members of the wrapped type, and return
Option!ReturnType.


> On the other hand, the suggested syntax of "bob?.department?.head?.name"  from Kotlin is pure genius, and has a good chance of actually being used.

Absolutely. Probably hard to include in D though, as a ? .b is the
beginning of a conditional expression.

-- 
Simen

>> On the other hand, the suggested syntax of "bob?.department?.head?.name" from Kotlin is pure genius, and has a
>> good chance of actually being used.
> 
> Absolutely. Probably hard to include in D though, as a ? .b is the beginning of a conditional expression.

How about

  bob??.department??.head??.name

On Tue, 21 Aug 2012 16:08:23 +0200, Carl Sturtivant <sturtivant@gmail.com> wrote:

>>> On the other hand, the suggested syntax of "bob?.department?.head?.name" from Kotlin is pure genius, and has a
>>> good chance of actually being used.
>>  Absolutely. Probably hard to include in D though, as a ? .b is the beginning of a conditional expression.
>
> How about
>
>    bob??.department??.head??.name

I guess that could work. Still won't happen though, but for other reasons.

Also, reminded me of C's WTF operator:

foo ??!??! exit(1);

-- 
Simen

On Tue, 21 Aug 2012 15:08:23 +0100, Carl Sturtivant <sturtivant@gmail.com> wrote:

>>> On the other hand, the suggested syntax of "bob?.department?.head?.name" from Kotlin is pure genius, and has a
>>> good chance of actually being used.
>>  Absolutely. Probably hard to include in D though, as a ? .b is the beginning of a conditional expression.
>
> How about
>
>    bob??.department??.head??.name

Hmm.. c# has another nice use for ??
http://msdn.microsoft.com/en-us/library/ms173224.aspx

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Tuesday, 21 August 2012 at 14:29:56 UTC, Simen Kjaeraas wrote:
> On Tue, 21 Aug 2012 16:08:23 +0200, Carl Sturtivant <sturtivant@gmail.com> wrote:
>
>>>> On the other hand, the suggested syntax of "bob?.department?.head?.name" from Kotlin is pure genius, and has a
>>>> good chance of actually being used.
>>> Absolutely. Probably hard to include in D though, as a ? .b is the beginning of a conditional expression.
>>
>> How about
>>
>>   bob??.department??.head??.name
>
> I guess that could work. Still won't happen though, but for other reasons.
>
> Also, reminded me of C's WTF operator:
>
> foo ??!??! exit(1);

That's brilliant. Surprised I haven't seen that before.

On 21/08/2012 14:30, Simen Kjaeraas wrote:
> On Tue, 21 Aug 2012 13:55:58 +0200, Regan Heath <regan@netmail.co.nz>
> wrote:
>
>> I don't buy the argument that having to explicitly type ".get" will
>> stop anyone from automatically coding statements like:
>>
>> val g: Option[T] = f.doSomething()
>> g.get.doSomethingElse()
>
> So don't give them that access?

Yes, or force conversion of the Option, handling the invalid case:

g.valueOrElse(null).doSomethingElse();

The above being explicit that null might be returned. The code is no safer, but it is much clearer. Also sometimes the caller has a better alternative value than null to use which is actually valid.

> I have an Option struct on my home computer that only allows access to
> the held value if the error case is simultaneously handled:
>
> Option!int a = foo();
>
> int n = a.match!(
>      (int x) => x,
>      (None n) => 0 // or throw, or what have you.
>      );
>
> The same solution is perfectly adaptable to MaybeNull, MaybeNan, and
> probably
> a host of others of the same family.
>
> With some clever use of opDispatch, one could write an Option struct that
> lets you call methods and acces members of the wrapped type, and return
> Option!ReturnType.

Apart from the opDispatch bit, I've been slowly working on something similar (Boost license):

https://github.com/ntrel/d-maybe/blob/master/maybe.d

I'm still working on it, but the basic ideas are there. I think the best bit is apply(), which supports passing multiple Maybe values, calling the delegate only if all Maybes are valid. In fact Maybe.map() is unnecessary due to apply().

Nick

Regan Heath:

> Plus, I don't buy the argument that having to explicitly type ".get" will stop anyone from automatically coding statements like:
>
> val g: Option[T] = f.doSomething()
> g.get.doSomethingElse()
>
> and suffering the exact same null pointer exception/error despite using Option and boxing into a Not-Null type.
>
> Like checked exceptions people will simply ignore the possibility of error and type the above anyway.  So, end result, it's just more typing for no real gain.

Mark C. Chu-Carroll is very intelligent and well read, most times he's right. My Scala experience is limited, so I don't first-hand how much Mark is right this time.

I think having a type for a reference/pointer that can't be null is useful. With it in many situations you need no "get", because there no risk of it being null. So the discussion here is for the other cases where you need a reference that can be null too. Such cases are surely just part of the cases where in D now you receive a generic nullable reference/pointer. So even if "get" is about as dangerous as normal references, the situation is better still.

Time ago I have suggested a syntax like Foo@ to represent in D the subtype of Foo references that can't be null.

Bye,
bearophile