views:

17378

answers:

14

.Net 3.5 doesn't support tuples. Too bad, But not sure whether the future version of .net will support tuples or not?

+50  A: 
#region tuples

    public class Tuple<T>
    {
        public Tuple(T first)
        {
            First = first;
        }

        public T First { get; set; }
    }

    public class Tuple<T, T2> : Tuple<T>
    {
        public Tuple(T first, T2 second)
            : base(first)
        {
            Second = second;
        }

        public T2 Second { get; set; }
    }

    public class Tuple<T, T2, T3> : Tuple<T, T2>
    {
        public Tuple(T first, T2 second, T3 third)
            : base(first, second)
        {
            Third = third;
        }

        public T3 Third { get; set; }
    }

    public class Tuple<T, T2, T3, T4> : Tuple<T, T2, T3>
    {
        public Tuple(T first, T2 second, T3 third, T4 fourth)
            : base(first, second, third)
        {
            Fourth = fourth;
        }

        public T4 Fourth { get; set; }
    }

    #endregion

And to make declarations prettier:

public static class Tuple
{
    //Allows Tuple.New(1, "2") instead of new Tuple<int, string>(1, "2")
    public static Tuple<T1, T2> New<T1, T2>(T1 t1, T2 t2)
    {
        return new Tuple<T1, T2>(t1, t2);
    }
    //etc...
}
dimarzionist
While the question is on MS providing it in .NET 4, this is a good way to manage it for now. +1
Chris Charabaruk
This inheritance approach is fine if you don't need to compare two Tuples for equality. I wanted to implement IEquatable<Tuple<T1, T2>> and so forth in my implementation, so I couldn't use inheritance, because I didn't want a Tuple<T1,T2> to be equal to a Tuple<T1,T2,T3,T4>.
Joel Mueller
@Joel, You can have Equals check the dynamic type of both arguments.
RossFabricant
How would you use it in code? t = new Tuple(1, 2); t.First and t.Second?
drozzy
See also another answer to similar question: http://stackoverflow.com/questions/955982/tuples-or-arrays-as-dictionary-keys-in-c/956043#956043
Benjol
@drozzy, no, you would have to do t = new Tuple<int, int>(1, 2);
Benjol
@dimarzionist, sorry for editing your post, I tried a comment but it was unreadable, feel free to delete or modify.
Benjol
+1 cause i agree with Chris Charabaruk
Amir
+1  A: 

If I remember my Computer Science classes correctly tuples are just data.

If you want grouped data - create classes that contain properties. If you need something like the KeyValuePair then there it is.

Tigraine
Just like if statements are just gotos with a block of statements. Tuples are nice if you have you are used to them and classes seem unneccessary and unwieldy in specific cases...
Daniel W
A: 

I'd be surprised - C# is a strongly-typed language, whereas tuples are suited for more dynamically typed languages. C# has been drifting more dynamic as time goes on, but that's syntactic sugar, not a real shift in the underlying data types.

If you want two values in one instance, a KeyValuePair<> is a decent substitute, albeit clumsy. You can also make a struct or a class that'll do the same thing, and is expandable.

Merus
"C# has been drifting more dynamic" - no, it has been drifting more implicit/inferred; it is still a fully static language. However, better dynamic support (for consuming DLR classes) is a very likely future language enhancement.
Marc Gravell
How do you explain the presence of tuples in F#, or Haskell, or any of the other strongly and statically typed languages that have full support for them then...?
Greg Beech
+7  A: 

In my opinion, the anonymous types feature is not a tuple, but a very similar construct. The output of some LINQ Queries are collections of anonymous types, which behave like tuples.

Here is a statement, which creates a typed tuple :-) on the fly:

var p1 = new {a = "A", b = 3};

see: http://www.developer.com/net/csharp/article.php/3589916

ChaosSpeeder
A: 

Check out http://www.firstdrafthell.net/?p=19 where I've implemented a very simple generic pair class.

Patrik
+3  A: 

C# supports simple tuples via generics quite easily (as per an earlier answer), and with "mumble typing" (one of many possible C# language enhancements) to improve type inference they could be very, very powerful.

For what it is worth, F# supports tuples natively, and having played with it, I'm not sure that (anonymous) tuples add much... what you gain in brevity you lose very quickly in code clarity.

For code within a single method, there are anonymous types; for code going outside of a method, I think I'll stick to simple named types. Of course, if a future C# makes it easier to make these immutable (while still easy to work with) I'll be happy.

Marc Gravell
One of the benefits is for things like TryParse, where you can write 'valid value = double.TryParse("1.02")' and have multiple return values assigned without any clumsy out parameters. But in general I agree that purely positional data structures aren't a great thing to pass around.
Greg Beech
Agreed - multiple return values is the best use case for tuples, and other than that there is very little purpose for tuples in code. That should be a convention rather than a restriction though where tuples are allowed. What I think would have been neater is if .NET languages provided a way to "disect" return objects into multiple values rather than introducing the tuple data type. Something like `{ j = ErrorCode, h = ResultObj } = SomeFunction()` (where `j` and `h` are locals) would have been much more helpful than tuples.
Walt W
+5  A: 

Implementing Tuple classes or reusing F# classes within C# is only half the story - these give you the ability to create tuples with relative ease, but not really the syntactic sugar which makes them so nice to use in languages like F#.

For example in F# you can use pattern matching to extract both parts of a tuple within a let statment, eg

let (a, b) = someTupleFunc

Unfortunately to do the same using the F# classes from C# would be much less elegant:

Tuple<int,int> x = someTupleFunc();
int a = x.get_Item1();
int b = x.get_Item2();

Tuples represent a powerful method for returning multiple values from a function call without the need to litter your code with throwaway classes, or resorting to ugly ref or out parameters. However, in my opinion, without some syntactic sugar to make their creation and access more elegant, they are of limited use.

Chris Ballard
How about anonymous types, then?
Chris Charabaruk
That allows you to replace Tuple<int,int> with var, but you still end up with three lines of code rather than one
Chris Ballard
Perhaps this is something we will see in C# 4.0. Syntactic sugar such as int a, b = someTupleFunc(); should be perfectly doable at a compiler level.
Adam Lassek
A: 

To make these useful in a hashtable or dictionary, you will likely want to provide overloads for GetHashCode and Equals.

+2  A: 

Here's my set of tuples, they're autogenerated by a Python script, so I've perhaps gone a bit overboard:

Link to Subversion repository

You'll need a username/password, they're both guest

They are based on inheritance, but Tuple<Int32,String> will not compare equal to Tuple<Int32,String,Boolean> even if they happen to have the same values for the two first members.

They also implement GetHashCode and ToString and so forth, and lots of smallish helper methods.

Example of usage:

Tuple<Int32, String> t1 = new Tuple<Int32, String>(10, "a");
Tuple<Int32, String, Boolean> t2 = new Tuple<Int32, String, Boolean>(10, "a", true);
if (t1.Equals(t2))
    Console.Out.WriteLine(t1 + " == " + t2);
else
    Console.Out.WriteLine(t1 + " != " + t2);

Will output:

10, a != 10, a, True
Lasse V. Karlsen
+11  A: 

There is a proper (not quick) C# Tuple implementation in Lokad Shared Libraries (Open-source, of course) that includes following required features:

  • 2-5 immutable tuple implementations
  • Proper DebuggerDisplayAttribute
  • Proper hashing and equality checks
  • Helpers for generating tuples from the provided parameters (generics are inferred by compiler) and extensions for collection-based operations.
  • production-tested.
Rinat Abdullin
+39  A: 

I've just read this article from the MSDN Magazine: Building Tuple

Here are excerpts:

The upcoming 4.0 release of Microsoft .NET Framework introduces a new type called System.Tuple. System.Tuple is a fixed-size collection of heterogeneously typed data.    

 

Like an array, a tuple has a fixed size that can't be changed once it has been created. Unlike an array, each element in a tuple may be a different type, and a tuple is able to guarantee strong typing for each element.

 

There is already one example of a tuple floating around the Microsoft .NET Framework, in the System.Collections.Generic namespace: KeyValuePair. While KeyValuePair can be thought of as the same as Tuple, since they are both types that hold two things, KeyValuePair feels different from Tuple because it evokes a relationship between the two values it stores (and with good reason, as it supports the Dictionary class).

Furthermore, tuples can be arbitrarily sized, whereas KeyValuePair holds only two things: a key and a value.


While some languages like F# have special syntax for tuples, you can use the new common tuple type from any language. Revisiting the first example, we can see that while useful, tuples can be overly verbose in languages without syntax for a tuple:

class Program {
    static void Main(string[] args) {
     Tuple<string, int> t = new Tuple<string, int>("Hello", 4);
     PrintStringAndInt(t.Item1, t.Item2);
    }
    static void PrintStringAndInt(string s, int i) {
     Console.WriteLine("{0} {1}", s, i);
    }
}

Using the var keyword from C# 3.0, we can remove the type signature on the tuple variable, which allows for somewhat more readable code.

var t = new Tuple<string, int>("Hello", 4);

We've also added some factory methods to a static Tuple class which makes it easier to build tuples in a language that supports type inference, like C#.

var t = Tuple.Create("Hello", 4);
Andreas Grech
A: 

My open source .NET Sasa library has had tuples for years (along with plenty of other functionality, like full MIME parsing). I've been using it in production code for a good few years now.

naasking
A: 

What's wrong in the below routine.

   public Tuple<int, int, int, int, int, int, int, Tuple<int>> CreateNewTuples1()
    {
        return Tuple.Create(1, 2, 3, 4, 5, 6, 7, Tuple.Create(8));

    }

I got the error.

    //Error 1   Cannot implicitly convert type 'System.Tuple<int,int,int,int,int,int,int,System.Tuple<System.Tuple<int>>>' to 'System.Tuple<int,int,int,int,int,int,int,System.Tuple<int>>'

So I modified the signature of the routine to have the following.

    public Tuple<int, int, int, int, int, int, int, Tuple<Tuple<int>>> CreateNewTuples()
    {
        return Tuple.Create(1, 2, 3, 4, 5, 6, 7, Tuple.Create(8));

    }

Its passed.

Is there any other way to do with this.

Neelakandan
This is a question, not an answer...
Benjol
A: 

There was an article about this recently on msdn

Daniel
@Daniel, I ask this question back in 2008, the tuple announcement hadn't come out by then.
Ngu Soon Hui
Sorry about that Ngu, i've edited the answer
Daniel