www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Optional<T> equivalent in D?

reply "Jacek Furmankiewicz" <jacek99 gmail.com> writes:
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?
Nov 15 2013
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
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.
Nov 15 2013
next sibling parent "Brad Anderson" <eco gnuk.net> writes:
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.
Nov 15 2013
prev sibling parent "Jacek Furmankiewicz" <jacek99 gmail.com> writes:
Thanks! std.typecons definitely looks like something I need to 
dig into.
Nov 15 2013
prev sibling next sibling parent reply Justin Whear <justin economicmodeling.com> writes:
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
Nov 15 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Nov 15 2013
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Nov 15 2013
next sibling parent reply "Meta" <jared771 gmail.com> writes:
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.
Nov 16 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, November 16, 2013 11:18:38 Meta wrote:

 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.


If you want to use the type system to try and protect against dereferencing 
null, then having wrapper which guarantees that the object _isn't_ null makes 
a lot more sense, particularly when just because you used Optional<T> instead 
of T mkaes no guarantees whatsoever that all of the other T's in the program 
are non-null. At best, if Optional<T> is used 100% consistently, you know that 
when a naked T is null, it's a bug.


 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.


Honestly, I pretty much never have problems with null pointers/references, and 
my natural reaction when I see people freaking out about them is to think that 
they don't know what they're doing or that they're just plain paranoid. That 
doesn't mean that my natural reaction is right. It could easily be the case 
that many such people are merely programming in environments different enough 
from anything I've had to deal with that null is actually a real problem for 
them and that it would be a real problem for me in the same situation. But in 
my experience, null really isn't a problem, and it can be  very useful. So, 
when people freak out about it and insist on trying to get the type system to 
protect them from it, it really baffles me. It feels like they're trying to
take 
a very useful tool out of the toolbox just because they weren't careful and 
managed to scratch themselves with it once or twice.

And Java's Optional seems even more useless, because it doesn't actually 
protect you against dereferencing null, and because it doesn't prevent 
anything which isn't in an Optional from being null.

Much as I don't think that it's worth it, I can at least see arguments for 
using NonNullable (which will end up in std.typecons eventually) to guarantee 
that the object isn't null, but I really don't think that using Optional or 
Nullable on a nullable type gains you anything except the illusion of 
protection.

Oh, well. null seems to be a very divisive topic. There are plenty of folks 
who are convinced that it's a huge disaster, and plenty of others who have no 
problems with it at all and consider it to be useful. And for some reason, it 
seems like the folks in Java land freak out over it a lot more than the folks 
in C++ land, and aside from D, C++ is definitely the language that I've used 
the most and am most comfortable with, as well as tend to agree with the 
proponents of the most (though obviously, it has plenty of flaws - hence why I 
prefer D).

- Jonathan M Davis
Nov 16 2013
parent "Meta" <jared771 gmail.com> writes:
On Saturday, 16 November 2013 at 23:34:55 UTC, Jonathan M Davis 
wrote:

 If you want to use the type system to try and protect against 
 dereferencing
 null, then having wrapper which guarantees that the object 
 _isn't_ null makes
 a lot more sense, particularly when just because you used 
 Optional<T> instead
 of T mkaes no guarantees whatsoever that all of the other T's 
 in the program
 are non-null. At best, if Optional<T> is used 100% 
 consistently, you know that
 when a naked T is null, it's a bug.


You're right, it's better to ensure that the object is not null 

Kotlin, and Rust do. D currently doesn't do this, and most 
developers probably won't have the discipline to use NonNull 
consistently throughout their code. The best we can do on that 
front is make sure it's used consistently within Phobos, so we 
can guarantee that we'll never give a user a null value.


 Honestly, I pretty much never have problems with null 
 pointers/references, and
 my natural reaction when I see people freaking out about them 
 is to think that
 they don't know what they're doing or that they're just plain 
 paranoid. That
 doesn't mean that my natural reaction is right.


I think in this case, your natural reaction is wrong, because 
you've used mostly languages with nullable references. It's a 
case of the blub fallacy: "Nullable references are good enough. 
Why bother with all that hairy non-nullable stuff?"


 It could easily be the case
 that many such people are merely programming in environments 
 different enough
 from anything I've had to deal with that null is actually a 
 real problem for
 them and that it would be a real problem for me in the same 
 situation. But in
 my experience, null really isn't a problem, and it can be  very 
 useful. So, when people freak out about it and insist on trying 
 to get the type system to
 protect them from it, it really baffles me. It feels like 
 they're trying to take
 a very useful tool out of the toolbox just because they weren't 
 careful and
 managed to scratch themselves with it once or twice.


I don't think anyone's freaking out about null, and you're right 
that null is useful. The question is, why do we need object 
references to be nullable by default? If they were non-nullable 
by default, we could eliminate a whole class of errors for free. 
Not for some arcane definition of free. This is a free lunch that 
is being refused. You seem to be asking the question "why do we 
need them", when you should be asking "what do we lose by not 
having them".

Note that I'm arguing for non-nullable references here, which D 
is obviously never going to have. The next best thing is, as you 
suggested, having a wrapper type that we can use to be reasonably 
sure never holds a null reference. Again, the problem with that 
is that it requires programmer discipline.


 And Java's Optional seems even more useless, because it doesn't 
 actually
 protect you against dereferencing null, and because it doesn't 
 prevent
 anything which isn't in an Optional from being null.


See, that's the problem. References are nullable by default in 
Java, so even with an Optional type and a NonNullable wrapper you 
can never be 100% that you're not dealing with null masquerading 
as an object. The truly safe thing would be to enforce in the 
language that all references are wrapped in Optional by the 
compiler, or make a language change to disallow null references, 
but doing either of those is not at all realistic. Still, 
creating a convention of avoiding objects that aren't wrapped in 
Optional among Java developers could get you pretty close.


 Much as I don't think that it's worth it, I can at least see 
 arguments for
 using NonNullable (which will end up in std.typecons 
 eventually) to guarantee
 that the object isn't null, but I really don't think that using 
 Optional or
 Nullable on a nullable type gains you anything except the 
 illusion of
 protection.


Well, again, Optional would force you to check that the 
underlying object was null before you used it. You simply can't 
call, say, calculatePrice() on a Nullable!SalesGood (well, you 
actually can due to the fact that Nullable aliases itself to the 
wrapped object, which is a huge mistake IMO).


 Oh, well. null seems to be a very divisive topic. There are 
 plenty of folks
 who are convinced that it's a huge disaster, and plenty of 
 others who have no
 problems with it at all and consider it to be useful. And for 
 some reason, it
 seems like the folks in Java land freak out over it a lot more 
 than the folks
 in C++ land, and aside from D, C++ is definitely the language 
 that I've used
 the most and am most comfortable with, as well as tend to agree 
 with the
 proponents of the most (though obviously, it has plenty of 
 flaws - hence why I
 prefer D).


I think "huge disaster" might be a mischaracterization on your 
part. There is no worldwide hysteria over nullable references, 
just a growing realization that we've been doing it wrong for the 
past 20 years. And yes, null is useful to indicate the absence of 
a value, but objects don't have to be nullable by default for you 
to use null. Many languages make the programmer ask for a 
nullable reference specifically by appending ? to the type, which 
makes everyone reading the code aware that the reference you have 
might be null, and to take appropriate care.
Nov 16 2013
prev sibling parent reply Max Klyga <email domain.com> writes:
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.
Nov 16 2013
parent Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/16/13 7:41 AM, Max Klyga wrote:

 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.


Null is only horrible if the compiler let's you dereference it... 
something that happens in almost every language out there.
Nov 16 2013
prev sibling next sibling parent "Michael" <pr m1xa.com> writes:
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
Nov 16 2013
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Sat, 2013-11-16 at 00:04 -0500, 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 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.


Maybe and Optional are far from pointless and returning null is anathema
if you want to use modern fluent approaches, streaming, and generally
getting things right.

Haskell has to do things this way because there is really no choice in
pure functional languages.

Scala, Ceylon, Kotlin do things analogously so as to integrate the OO
and functional approaches into what is rapidly becoming the programming
norm. Java 8 is the beginning of Java requiring that null never be
returned from a method call. And likely soon the demise of all primitive
types in favour of efficient boxing and unboxing of reference types
(unlike what happens at present).

"Dealing with null properly" is simply a remnant of 1994 era thinking,
we have long-ago moved past this.

-- 
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
Nov 16 2013