Is there some sort of generic bound in Java?

Question

I am defining a type Option<T> in Java that should behave as much as possible as Rust's equivalent.

It has a method, Option::flatten, that is only implemented if the inner T is some other Option<T>. I am thinking of something like this:

public class Option<T> {
    /* fields, constructors, other methods */

    @Bound(T=Option<U>)
    public <U> Option<U> flatten() {
        if (isNone()) return None();
        else return this.unwrap();
    }
}

But the syntax is of course completely fictional. Is there some way to make this work in Java? I know static methods are an option, but they can't be called like a normal method which is the only goal of this type.

---

This is not supposed to be a standalone thing, but rather a part of a larger Java implementation of Rust iterators I'm currently working on.

Answer 1

The problem with trying to come up with a non-static method such as flatten is that in Java one cannot conditionally add more methods to a class based on whether the type parameter of the class fulfills a certain constraint.

You can, however, make it a static method and constrain its arguments to whatever you need.

class Option<T> {
    // ...
    public static <U> Option<U> flatten(Option<Option<U>> option) {
        if (option.isNone()) return None();
        return option.unwrap();
    }
}

Which would work for valid implementations of None, isNone and unwrap.

---

A more complete example follows.

public static class Option<T> {
    private final T value;
    
    private Option(T x) {
        this.value = x;
    }
    
    public static <T> Option<T> of(T x) {
        java.util.Objects.requireNonNull(x);
        return new Option<>(x);
    }

    public static <T> Option<T> None() {
        return new Option<>(null);
    }
    
    public T unwrap() {
        java.util.Objects.requireNonNull(this.value);
        return this.value;
    }
    
    public boolean isNone() {
        return this.value == null;
    }

    public static <U> Option<U> flatten(Option<Option<U>> option) {
        if (option.isNone()) return Option.None();
        return option.unwrap();
    }
    
    @Override
    public String toString() {
        if (this.isNone()) {
            return "None";
        }
        return "Some(" + this.value.toString() + ")";
    }
}

Usage:

var myOption = Option.of(Option.of(5));
System.out.println("Option: " + myOption);
System.out.println("Flattened: " + Option.flatten(myOption));

Output:

Option: Some(Some(5))
Flattened: Some(5)

Answer 2

I think the way you want to handle this is not to actually have a flatten() method, but have different handling in your constructor. Upon being created, the constructor should check the type it was handed. If that type is Option, it should try and unwrap that option, and set its internal value to the same as the option it was handed.

Otherwise, there isn't really a way for an object to 'flatten' itself, because it would have to change the type it was bounded over in the base case. You could return a new object from a static method, but are otherwise stuck.

Answer 3

I want to point out some of the potential headaches and issues regarding this re-implementation of Optional<T>.

Here's how I would initially go about it:

public class Option<T> {
    /* fields, constructors, other methods */

    public <U> Option<U> flatten() {
        if (isNone()) return None();
        T unwrapped = this.unwrap();
        if (unwrapped instanceof Option) {
            return (Option<U>) unwrapped; //No type safety!
        } else {
            return (Option<U>) this;
        }
    }
}

However, this code is EVIL. Note the signature of <U> Option<U> flatten() means that the U is going to be type-inferenced into whatever it needs to be, not whatever a potential nested type is. So now, this is allowed:

Option<Option<Integer>> opt = /* some opt */;
Option<String> bad = opt.flatten();
Option<Option<?>> worse = opt.<Option<?>>flatten();

You will face a CCE upon using this for the other operations, but it allows a type of failure which I would say is dangerous at best. Note that any Optional<Optional<T>> can have #flatMap unwrap for you: someOpt.flatMap(Function.identity());, however this again begs the question of what caused you to arrive at a wrapped optional to begin with.

Another answer (by @NathanielFord) notes the constructor as an option, which seems viable as well, but will still face the runtime check upon construction (with it simply being moved to the constructor):

public class Option<T> {
    /* fields, constructors, other methods */

    public Option<T>(T someValue) { ... }
    public Option<T>(Option<T> wrapped) {
        this(wrapped.isNone() ? EMPTY_OBJECT : wrapped.unwrap());
    }

    public Option<T> flatten() {
        return this; //we're always flattened!
    }
}

Note as well, the re-creation of Optional<T> by @E_net4thecommentflagger has the potential for a nasty future bug: Optional.ofNullable(null).isNone() would return true! This may not be what you want for some potential use-cases, and should #equals be implemented in a similar manner, you'd end up with Optional.ofNullable(null).equals(Optional.None()), which seems very counter-intuitive.

All of this to say, that while Rust may require you to deal with these nested optionals, you are writing code for Java, and many of the potential restrictions you faced before have changed.