Tuple Class

There is no method documented here other than a constructor and a static 'create'.  The example is absolutely hilarious - just a constructor. 

So, um, how do you get data out?

The answer is you can access the elements as Item1, Item2, etc.  But, seems like an incredibly basic fact to leave out of the documentation, which makes this look like a write-once, non-readable datastructure.

Tuple Class and Tuples

I can see your point, but at the same time I don't agree. If other developers have strong feelings here, we'd like to hear about them. This topic has already been revised once to add content that we didn't feel belongs here, and we'd be happy to revise it again if there is sufficiently strong feeling.

In any case, the basic problem from a documentation perspective is that the Tuple class does not itself represent a Tuple. It's simply a factory class that allows you to create eight of the potentially infinite number of tuple types supported by the .NET Framework. The actual tuple types are represented by Tuple(<T1>) through Tuple(<T1>, T2, T3, T4, T5, T6, T7, TRest). As a factory class, Tuple is simply intended to provide convenience methods -- the same functionality is available from the individual tuple type's class constructor, but it requires a slightly greater degree of complexity and a good deal of additional coding. So the Tuple class can be used to create a tuple, but it can't be used to get data out, since it has only static factory methods. As a result, the "example" here is a one-liner that shows how to call a factory method and how that compares to a call to the corresponding class constructor; anything else simply would be out of place here. The documentation on getting data out, along with complete examples, is found in the documentation for each of the actual tuple types, which is where we believe that it logically belongs. We expect that developers who want information on the actual tuple types and their functionality to follow the appropriate link to a specific tuple type.

In any case, that accounts for why the documentation for the Tuple class appears as it does; it's a deliberate content decision. It also may be a poor decision. If so, we'd like to hear some additional opinions.

--Ron Petrusha
Common Language Runtime User Education
Microsoft Corporation

If you want to pass data around and have a getter setter; why not use an array? What is the difference?

Why Not Use an Array?

Certainly an array is a viable option if you want to pass data to a method and be able to modify it. So is a custom data type, such as a program-defined structure or class. Which a developer chooses is often a matter of personal preference and programming style.

Tuples tend to have three major advantages:

1. Unlike arrays, they are structured data types. Although you can impose a structure on arrays (for example, the first element of an array can represent an index, the second can represent a name, the third can represent an age, etc.), an array is not inherently structured. In contrast, a tuple type, as a generic type, is strongly typed at runtime. (Note that you could use a generic array type, such as List<T>, instead, but this requires that each element of the array have the same type. A tuple does not.)
2. Because they are strongly typed, tuples should offer better performance than arrays. The performance improvement, however, is not likely to be signfiicant unless an application makes use of a large number of tuples.
3. When you have to manipulate multiple items at the same time, using an array (or an ArrayList) of tuples is fairly intuitive, as long as you remember what each tuple item represents. Many of the tuple examples in our documentation, for instance, pass an List<T> of some tuple type to some routine for processing, sorting, or filtering. In contrast, if you choose to use an array, you have to use nested arrays. These are somewhat more cumbersome to work with, and some developers find them awkward, confusing, or difficult.

 --Ron Petrusha
Common Language Runtime User Education
Microsoft Corporation
 

It a step on the right direction, but still found wanted.
I think it would be extremely useful if you could add structural inheritance semantics into the tuples.
Together with named parameters, is could be so cool! e.g.,

//tuple that represents a person:
Tuple<int, String> preson = Tuple.Create(name: "John", age: 31);
//a tuple which represents an employee, which structurally inherits person:
Tumple<int, String, String> superHacker = Tuple.Create(name: "Elior", age:29, profession: "Programmer");
//and so (with some compiler modification), the following could be supported:
person = superHacker;

Extension of Tuple?

I've passed on your suggested modifications to the tuple types to the feature team. They will be considered for possible inclusion in a forthcoming version of the .NET Framework. Thanks for your feature suggestion.

--Ron Petrusha
Common Language Runtime User Education
Microsoft Corporation

@Matt: Then the Tuple is highly recommended by the American Heart Association.

The documentation does not state this, but after creating the tuple, the items that are created by it are read-only as there is no setter.

Imagine that you want to work with some blood pressure data in a quick and dirty bit of code.  Instead of making a blood pressure class to just store systolic and diastolic values, maybe you just make a new Tuple<int, int> by calling Tuple.Create(120, 80).  A Tuple just lets you hold some data together in lieu of writing a whole class or struct to do it.  A two item tuple is a pair, a three item tuple is a triple, etc.  Anonymous types are typically localized to a method, so they don't work well for passing around.  Using a tuple lets you widen the scope and return tuples from methods.  My personal opinion is that they are useful for internal storage within a class where you might create an internal struct or class, but they shouldn't be exposed outside of class scope.