CODEWITHSUNDEEP
javac++java-streammonadsoption-type
towi
towi

Reputation: 22347

Java-Optional versus C++-optional

Am I right in assuming that the Java-Optional does not have much todo with the C++17-optional?

I know Javas Optional mostly from use in the Stream-API, e.g.:

Optional<Integer> op  = Optional.empty(); 
op.stream().forEach(System.out::println);

I know it has its uses as a return value as well (not so much as parameter). But concerning this kind of use this is not applicaple to the C++-optional, right?

Or is it "Monads" again, the thing no-one can explain after understanding it? Does the C++-optional have in fact everything to do with Monads, and so have Java-Streams, and thus C++--optional is comparable to Java-Optional? What would be an comparable example, then?

Upvotes: 1

Views: 1035

Answers (2)

Sweeper
Sweeper

Reputation: 275015

Am I right in assuming that the Java-Optional does not have much todo with the C++17-optional?

They are similar in that they kind of model the same concept - a value that can be absent, but their interfaces are very different. I am not very knowledgable about C++, but looking at this page, I can see that C++'s std::optional is a lot less functional than Java's Optional.

Or is it "Monads" again, the thing no-one can explain after understanding it?

Spot on! Java's Optional is essentially a monad. By having Optional.of, and Optional.flatMap methods, the Java Optional becomes a monad. The C++ optional lacks a corresponding flatMap method, which causes it to not be a monad :(

IMO, std::optional not having a flatMap method is the fundamental between the two types in question. flatMap has the signature:

<U> Optional<U> flatMap(Function<? super T, Optional<U>> mapper)

Essentially allowing you to compose Optionals. You can have a Optional<String>, apply a function that returns another Optional<T> to it, and then get back an Optional<T>.

Here is a paper about Monads that might help. Monads aren't really that scary. The key feature is a function with the same signature as flatMap shown above. If you see something like that, there's a good chance you've found a monad! Stream is therefore a monad.

Upvotes: 1

Tolik Pylypchuk
Tolik Pylypchuk

Reputation: 680

Optionals in Java and in C++ (and in a lot of other programming languages) serve a similar purpose - to represent a value that may be present or absent.

Optionals in Java are not only used for streams, they can (and should) be used in their own right. That being said, in Java optionals should be used only as return types of methods that may or may not return a value. The same can be achieved with returning null values, but with that it's much easier to forget to check the returned value. But optionals in Java aren't supposed to just replace every object that may not actually be present (like Maybe in Haskell, for example).

I'm not an expert in C++, but it looks like C++'s optional has largely the same purpose (correct me if I'm wrong).

I won't explain what monads are here, but the concept is quite easy and I really don't know why so many people are afraid of them. If you've read anything about monads, you know that they basically have 2 operations: create a monadic value, and bind it (or flat-map it).

In Java, Optional.of creates an optional value, and Optional.flatMap, well, flat-maps it. But these operations don't fully respect the monadic laws, so purists claim that optionals in Java are not really monads.

In C++, you can create an optional using the constructor or the make_optional function, so you have the operation of creation. But I can't find the bind or flat_map function in the standard library. If you wish, you can write one yourself - then if that function respects the monadic laws, the optional will become a monad.

Upvotes: 1

Related Questions