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 in the first place, which is what languages like Haskell, Spec#, 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