Working with Tuple in C# 4.0

After writing about C# 5.0, you might be wondering why I moved a step behind with C# 4.0. Hey, I will definitely keep my promise to write a good blog on new async and await feature, but it is taking a bit time to go on. C# 4.0 being officially released contains lots of thoughts and approaches that come handy in many places. There are lots of new features introduced with C# 4.0 where a few of them are really very handy.

Today, I will write about a very handy object introduced in FCL named Tuple which can store n - number of values in it. Yes, you specify the type of each of those variables as generic parameters, and the object will create those values for you. Let's see how it works.

Using a Tuple

Base class library exposes two objects. It exposes the static class Tuple which allows you to get a number of Tuple instances based on the Static method Create, and a number of Tuple classes, each of which takes some specific number of Generic arguments.

• Tuple.Create<t1>
• Tuple.Create<t1,t2>
• Tuple.Create<t1,t2,t3>
• Tuple.Create<t1,t2,t3,t4>
• Tuple.Create<t1,t2,t3,t4,t5>
• Tuple.Create<t1,t2,t3,t4,t5,t6>
• Tuple.Create<t1,t2,t3,t4,t5,t6,t7>
• Tuple.Create<t1,t2,t3,t4,t5,t6,t7,t8>

Tuple.Create has 8 overloads and each of these overloads returns new object of Tuple<t1, t2...t8> class. So .NET Framework exposes 8 different classes, each of them taking T1..... T8 number of arguments and each of them exposes Item1..... Item8 number of arguments.

The Tuple class can be instantiated directly as well without using static objects. Even if you see in Reflector, all the Create methods actually return its respective Tuple object.

Hence, let's create object of Tuple.

Tuple<int, string> tuple = new Tuple<int, string>(20, "Abhishek");

Here, the class with two Generic Type arguments is created and hence it exposes the items as Item1 and Item2.

Similar to this, you can also create Tuple of 3, 4, 5 .....7 types

How to generate N number of argument list?

Tuple actually supports more than 8 argument as it expects the 8^th argument as another Tuple. Say for instance, if you write:

Tuple<int, string,int,int,int,int,int,int> tuple = 
    new Tuple<int, string,int,int,int,int,int,int>(20, "Abhishek", 39, 39,59,49,30, 33);

You will eventually end up with an ArgumentException.

Hence the appropriate call to it must be:

Tuple<int, string,int,int,int,int,int,tuple<int>> tuple = 
   new Tuple<int, string,int,int,int,int,int,tuple<int>>(20, 
   "Abhishek", 39, 39,59,49,30, new Tuple<int>(33));

So you can see the last generic argument we pass as Tuple. Using this argument, you can create as many arguments as you want.

Is Tuple a collection?

Hmm, it must be an interesting question. But it's not. Generally, we call an object to be a collection only when all the elements inside the object are of same Type. In case of Tuple, each type might differ based on the Type argument, hence it's not a collection.

Know a bit more .....

For enthusiastics, let me put this a bit further. After working for a while with Tuple, I was thinking why didn't Microsoft expose an interface to define each of these Tuple classes (say ITuple) and restrict the last argument TRest (8^th argument) using Generic constraint? To see what was the problem, I tried to dissemble it and have seen few strange designs.

1. Each Tuple is implemented from an Internal interface ITuple.
2. ITuple cannot be accessed from outside and is kept hidden.
3. Generic Constraint is not used for TRest while it throws ArgumentException intentionally from the constructor.

Interesting to Know

It should be noted, ToString is being implemented very well with Tuple objects. It puts the value as comma separated string with first braces around it.
So:

Tuple<int, string,int,int,int,int,int,Tuple<int>> tuple = 
    new Tuple<int, string,int,int,int,int,int,Tuple<int>>(20, 
    "Abhishek", 39, 39,59,49,30, new Tuple<int>(33));

Console.WriteLine(tuple);

It will actually print:

(20, Abhishek, 39, 39, 59, 49, 30, 33)

Cool, huh! I hope you would use Tuple in your code very often.

Thanks for reading!