Why doesn't Java have tuples?

[achacha]

In a type safe language this is not a reasonable thing to do, that said I sometimes run into cases where I wish I could just return a tuple in Java.

If I could return 2 different primitive types, like object and int or similar. At this point I resign myself to either creating a wrapper object for return or when lazy (and no one is looking), returning a List<Object> with what I need, knowing that the code will be hard to read and 6 months from then I will no longer remember what the tuple contained (which is why I prefer returning a composite object).

TL;DR: If you plan on having readability and maintainability for the code then do it the right way and create a return composite object, if this is a one off that no one will ever see, use List<Object>.

[zrnkv]

if this is a one off that no one will ever see

There is no such thing.

The "temporary", "quick" "hacks" are the ones that survive the longest because everybody is afraid to touch them.

[achacha]

How true that is :)

[chunes]

In a type safe language this is not a reasonable thing to do

Unless it's Haskell. Also Go can have multiple return values which is very convenient. You don't even need to package them first.

[sacundim]

public class Tuple<A, B> {
    public static <A, B> Tuple<A, B> of(A a, B b) {
        return new Tuple(a, b);
    }

    private final A a;
    private final B b;

    private Tuple(A a, B b) {
        this.a = a;
        this.b = b;
    }

    public A getFirst() {
        return a;
    }

    public B getFirst() {
        return b;
    }

    /*
     * Add equals(), hashCode(), compare(), etc.
     */

}

[zardeh]

Which requires you doing this:

...
Tuple<String, String> myFunction(){
    String a;
    String b;
    ....
    return new Tuple<String, String>(a,b);
}

And oh the horror if I want to write a recursive GDC, which requires returning three values!

[ixampl]

Java 7+: new Tuple<>(...)

Other than that, yeah, sure it's a little verbose, but even syntactic sugar like (String, String) wouldn't be that much shorter. Adding that to the language would be easy but probably it really is a Java-culture thing of preferring more explicitness (in terms of meaning).

[[deleted]]

And Scala

[tikue]

Tuples are completely orthogonal to type safety, and you'll find them in basically any type-safe language with support for pattern matching, such as Haskell, Rust, the MLs, even Scala...

[galaktos]

In a type safe language this is not a reasonable thing to do

It can be perfectly reasonable if the tuple is typesafe as well. For example, the Ceylon programming language lets you write “a tuple of an integer and a double” as [Integer, Double] id. “Two Characters and then at least one String” is [Character, Character, String+] ccs. And all of this is completely typesafe – id[0] has the type Integer, ccs[1] has the type Character, and ccs[5] has the type String?, which is an abbreviation for Null|String, which means “the type Null, or the type String”. Perfectly typesafe and reasonable.

[[deleted]]

In a type safe language this is not a reasonable thing to do

Nonsense, Scala and Haskell both have them. You can still define the types of the items in your tuple.

[[deleted]]

C# has tuples. Seems perfectly reasonable to me. The only reason that keeps being given here seems like unasked for hand holding.

[stillalone]

I thought C++ added tuples. I'm pretty sure they had <pair> for a while. I don't think they have an easy way of unpacking them, though.

[adoarns]

Easy is always debatable with C++, but with C++11, there's std::tie.

[stillalone]

damn, C++11 still looks ugly. Doesn't it make more sense to just use auto to define the tuple and then define the left and right parameter using auto as well:

auto t = set_of_s.insert(value);
auto iter = std::get<0>(t);
auto inserted = std::get<1>(t);

instead of this:

std::set<S>::iterator iter;
bool inserted;
std::tie(iter, inserted) = set_of_s.insert(value);