What requirement was the tuple designed to solve?

When writing programs it is extremely common to want to logically group together a set of values which do not have sufficient commonality to justify making a class.

Many programming languages allow you to logically group together a set of otherwise unrelated values without creating a type in only one way:

void M(int foo, string bar, double blah)

Logically this is exactly the same as a method M that takes one argument which is a 3-tuple of int, string, double. But I hope you would not actually make:

class MArguments
{
   public int Foo { get; private set; } 
   ... etc

unless MArguments had some other meaning in the business logic.

The concept of “group together a bunch of otherwise unrelated data in some structure that is more lightweight than a class” is useful in many, many places, not just for formal parameter lists of methods. It’s useful when a method has two things to return, or when you want to key a dictionary off of two data rather than one, and so on.

Languages like F# which support tuple types natively provide a great deal of flexibility to their users; they are an extremely useful set of data types. The BCL team decided to work with the F# team to standardize on one tuple type for the framework so that every language could benefit from them.

However, there is at this point no language support for tuples in C#. Tuples are just another data type like any other framework class; there’s nothing special about them. We are considering adding better support for tuples in hypothetical future versions of C#. If anyone has any thoughts on what sort of features involving tuples you’d like to see, I’d be happy to pass them along to the design team. Realistic scenarios are more convincing than theoretical musings.

Leave a Comment