What is the difference between Tuple and keyvaluepair

Question

I am not understanding the difference between tuple and keyvaluepair. i was looking into this article http://www.dotnetperls.com/tuple-keyvaluepair. it seems like tuple is better than keyvaluepair but some of the developers saying strictly do not use tuple i wonder why?

Answer 1

The KeyValuePair<> is a struct that represents a key and a value. When you enumerate a dictionary, the items are of the type KeyValuePair<> with the same generic types as the dictionary.

The Tuple<> classes are intended to represent multiple values, but there is no specific roles for the values like key or value. There are diffent Tuple<> classes for different number of values, from 1 up to 8 values.

The Tuple<> classes have names for the items like Item1, Item2, Item3 and so on. As those names doesn't tell you anything about what the items represent, you should preferably only use tuples where the meaning is obvious, for example quarters in a year.

Answer 2

There are quite a few people that call themselves developers that should not. Having said that. The link that you posted goes into some detail about the differences and when you should use them. In the end it depends on the application that you're building.

Quoted from the site you linked...

I recommend avoiding KeyValuePair entirely and using Tuple or custom classes (which would be similar to Tuple in performance).

and

Tuple was faster in every test than KeyValuePair except in allocation performance. Therefore, if your program does any work beyond allocating the collections, it is a better idea to use Tuple instead of KeyValuePair.

Illustrate the point I'm trying to make.

For the big toolset that developers can use, when people tell me to never use something that's usually when I stop caring about their opinion. Nobody should tell you what to use without getting the context of the type of use it's going to get.

Answer 3

I think those programmers are saying not to use Tuples because on a public API, they are less effective.

Lets say you have a tuple like

Tuple<int,string,string,int>

then how will you identify that what are these values later or what they are representing. I think thats why programmers say that. Like in this case the consumer has to either guess or look up documentation to know what you mean.

The MSDN says:

A tuple is a data structure that has a specific number and sequence of elements.

Tuples are commonly used in four ways:

• To represent a single set of data. For example, a tuple can represent a database record, and its components can represent individual fields of the record.
• To provide easy access to, and manipulation of, a data set.
• To return multiple values from a method without using out parameters (in C#) or ByRef parameters (in Visual Basic).
• To pass multiple values to a method through a single parameter. For example, the Thread.Start(Object) method has a single parameter that lets you supply one value to the method that the thread executes at startup time. If you supply a Tuple object as the method argument, you can supply the thread’s startup routine with three items of data.

Answer 4

They say don't use Tuple because Tuple has properties that don't have meaningful names: Item1, Item2, etc. Under some circumstances it's perfectly ok to use them. It is certainly less work to use a Tuple than to create your own every time.

One significant difference is that KeyValuePair is a struct and Tuples are classes. KeyValuePair has no relation to Tuples, really. It existed before Tuples to store keys and values in Dictionaries.

You could argue about whether Tuples should have been implemented as value types instead. The ones you use most are the ones with few Type parameters and they would be better as value types. (You easily implement them yourself) Look here to see why they made certain decisions: http://msdn.microsoft.com/en-us/magazine/dd942829.aspx#id0400060