Many other languages are starting to frown on returning null values from methods (due to NullPointerException risks, etc) and wrapping them instead in an Optional<T> like in

Scala:
http://blog.danielwellman.com/2008/03/using-scalas-op.html

Google Guava for Java: (now rolled into the base JDK for Java 8):
https://code.google.com/p/guava-libraries/wiki/UsingAndAvoidingNullExplained

Is there a similar approach in D? Or maybe an equivalent is in a commonly used external library?

On Friday, 15 November 2013 at 22:39:40 UTC, Jacek Furmankiewicz wrote:
> Many other languages are starting to frown on returning null values from methods (due to NullPointerException risks, etc) and wrapping them instead in an Optional<T> like in
>
> Scala:
> http://blog.danielwellman.com/2008/03/using-scalas-op.html
>
> Google Guava for Java: (now rolled into the base JDK for Java 8):
> https://code.google.com/p/guava-libraries/wiki/UsingAndAvoidingNullExplained
>
> Is there a similar approach in D? Or maybe an equivalent is in a commonly used external library?

Sounds like std.typecons.Nullable to me.

On Friday, 15 November 2013 at 22:41:40 UTC, Brad Anderson wrote:
> On Friday, 15 November 2013 at 22:39:40 UTC, Jacek Furmankiewicz wrote:
>> Many other languages are starting to frown on returning null values from methods (due to NullPointerException risks, etc) and wrapping them instead in an Optional<T> like in
>>
>> Scala:
>> http://blog.danielwellman.com/2008/03/using-scalas-op.html
>>
>> Google Guava for Java: (now rolled into the base JDK for Java 8):
>> https://code.google.com/p/guava-libraries/wiki/UsingAndAvoidingNullExplained
>>
>> Is there a similar approach in D? Or maybe an equivalent is in a commonly used external library?
>
> Sounds like std.typecons.Nullable to me.

I recommend having a look around std.typecons while you are in there.  It's got a lot of gems that seem to go unnoticed by a lot of people.

Thanks! std.typecons definitely looks like something I need to dig into.

On Fri, 15 Nov 2013 23:41:38 +0100, Brad Anderson wrote:

> On Friday, 15 November 2013 at 22:39:40 UTC, Jacek Furmankiewicz wrote:
>> Many other languages are starting to frown on returning null values
>> from methods (due to NullPointerException risks, etc)
>> and wrapping them instead in an Optional<T> like in
>>
>> Scala: http://blog.danielwellman.com/2008/03/using-scalas-op.html
>>
>> Google Guava for Java: (now rolled into the base JDK for Java 8): https://code.google.com/p/guava-libraries/wiki/
UsingAndAvoidingNullExplained
>>
>> Is there a similar approach in D? Or maybe an equivalent is in a commonly used external library?
> 
> Sounds like std.typecons.Nullable to me.

No, Nullable adds a potential null state to value types, e.g. it allows you to null an int.  To the best of my knowledge there is no Maybe/ Optional type in Phobos, but they're extremely easy to implement yourself.  Here's a Maybe type that I just threw together: http:// dpaste.dzfl.pl/e4b762ed

Justin Whear:

> No, Nullable adds a potential null state to value types, e.g. it allows you to null an int.

In std.typecons there is another version of Nullable, that uses a state as "null". So you can use it as nullable class reference. Is that good enough for the OP?

Bye,
bearophile

On Friday, November 15, 2013 23:39:38 Jacek Furmankiewicz wrote:
> Many other languages are starting to frown on returning null values from methods (due to NullPointerException risks, etc) and wrapping them instead in an Optional<T> like in
> 
> Scala: http://blog.danielwellman.com/2008/03/using-scalas-op.html
> 
> Google Guava for Java: (now rolled into the base JDK for Java 8): https://code.google.com/p/guava-libraries/wiki/UsingAndAvoidingNullExplained

I really don't understand this. Optional<T> is one of the most useless ideas that I've ever seen in Java. Just use null. It's built into the language. It works just fine. And wrapping it in a class isn't going to make it go away. Just learn to deal with null properly. I've known many programmers who have no problems with null whatsoever, and I'd be worried about any programmer who is so scared of it that they feel the need to wrap nullable objects in another type which has its own concept of null.

The only types which aren't nullable in Java are the primitive types, and if you use them in generics (like Optional<T> does), then you get a class that boxes the primitive type rather than using the primitive type directly, and that object is of course nullable. So, you might as well just use the class that boxes the primitive type directly and set its reference to null when you need it to be null. And Optional<T> doesn't even protect against null, since it's perfectly possible to make its contents null. So, as far as I can see, Optional<T> is utterly pointless. IMHO, it's outright bad software design.

> Is there a similar approach in D? Or maybe an equivalent is in a commonly used external library?

We have std.typecons.Nullable. However, it's real value is in making it possible to have value types be null. I very much hope that no one is using it like Optional<T> to set nullable types to null without actually using null. The _only_ nullable type in D that I would consider reasonable to use with Nullable would be arrays, and that's because of how null arrays aren't properly distinguishable from empty arrays, making using "is null" with them a bit iffy.

- Jonathan M Davis

On Friday, 15 November 2013 at 22:39:40 UTC, Jacek Furmankiewicz wrote:
> Many other languages are starting to frown on returning null values from methods (due to NullPointerException risks, etc) and wrapping them instead in an Optional<T> like in
>
> Scala:
> http://blog.danielwellman.com/2008/03/using-scalas-op.html
>
> Google Guava for Java: (now rolled into the base JDK for Java 8):
> https://code.google.com/p/guava-libraries/wiki/UsingAndAvoidingNullExplained
>
> Is there a similar approach in D? Or maybe an equivalent is in a commonly used external library?

You may find this useful http://www.m1xa.com/en/article/d-language-chained-null-checks-maybe-monad.html

On Saturday, 16 November 2013 at 05:04:42 UTC, Jonathan M Davis wrote:
> I really don't understand this. Optional<T> is one of the most useless ideas
> that I've ever seen in Java. Just use null. It's built into the language. It
> works just fine. And wrapping it in a class isn't going to make it go away.
> Just learn to deal with null properly. I've known many programmers who have no
> problems with null whatsoever, and I'd be worried about any programmer who is
> so scared of it that they feel the need to wrap nullable objects in another
> type which has its own concept of null.

The value of an Option<T> type is that it moves checking for null into the type system. It forces you to check for null before you perform any potentially NullPointerException-throwing operations, whereas using naked class references in Java, it's easy to forget, or miss a null check, or just ignore it and hope everything is fine. With Option<T>, you have no choice but to check for null before you perform an operation on the wrapped class reference.

> The only types which aren't nullable in Java are the primitive types, and if
> you use them in generics (like Optional<T> does), then you get a class that
> boxes the primitive type rather than using the primitive type directly, and
> that object is of course nullable. So, you might as well just use the class
> that boxes the primitive type directly and set its reference to null when you
> need it to be null. And Optional<T> doesn't even protect against null, since
> it's perfectly possible to make its contents null. So, as far as I can see,
> Optional<T> is utterly pointless. IMHO, it's outright bad software design.

I would have to respectfully disagree with that. Proper use of an Option<T> type can dramatically reduce the chance of calling a method on a null object, or even eliminate it entirely.

On 2013-11-16 05:04:20 +0000, Jonathan M Davis said:

> I really don't understand this. Optional<T> is one of the most useless ideas
> that I've ever seen in Java. Just use null.

Optional specifies explicitly that value can be absent and forces client to check before using the value.
Also, if Optional implements monadic interface one can easily chain computations depending on the state of optional values.

Even if references are nullable by default users do not check them for null on every usage. NullPointerException and the like are almost always indicators of programming error.

Null is just horrible.