When to use: Tuple vs Class c# 7.0
Before Tuples, I used to create a class and its variables then create object from this class and make that object the return type for some functions.
Now with the tuples I can do the same and in c# 7.0 we can assign understandable names for tuples properties (before this it was item1, item2, etc..)
So now I am wondering, when should I use it's and when should I create a class in c# 7.0?
Answer
As this answer is causing some confusion amongst some folk here, I should clarify that - as per the question - all references to "tuple" here refer to the ValueTuple type and new tuple syntactic sugar features of C# 7 and in no way refer to the old System.Tuple reference types.
So now I am wondering, when Should I use tuples and when Should I create a class in c# 7.0?
Only you can really answer that question as it really depends on your code.
However, there are guidelines and rules you can follow in guiding you in choosing between them:
Tuples are values, so are copied by value, rather than by reference.
Most of the time, this should not be an issue. However, if you are passing around tuples of large structs, this might have an impact on performance. Ref locals/returns can be used to work around these performance issues, though.
Additionally, because they are values, modifying a copy remotely will not change the original copy. This is a good thing, but could catch some folk out.
Tuple element names are not persisted
The names given to elements are used by the compiler and (in most cases) are not available at run-time. This means that reflection cannot be used to discover their names; they cannot be accessed dynamically and they cannot be used in razor views.
Also this is an important consideration with APIs. A tuple returned from a method is the exception to the rule regarding after-compilation name discoverability. The compiler adds attributes to the method that hold information on the tuple names. This means you can safely return a tuple from a public method in one assembly and access its names in another.
Tuples are lightweight
Tuples are much simpler to write than types as they are less verbose and the declaration can be "inlined" (ie declared at the point of use). This works well when declaring a method that returns multiple values, for example.
However, because they are declared at the point of use, if you have MethodA that calls MethodB that calls MethodC and each returns a tuple, you'll need to redefine the tuple at every stage. There isn't (yet) a way of creating an alias of a tuple and re-using it across multiple methods.
Just use common sense
For any situation where you might consider using a tuple: simply ask yourself the question: "will a tuple simplify the code here". If the answer is "yes", then use one. And that ultimately is the primary consideration over whether to use a tuple or a custom class.