Any reason to use out parameters with the C# 7 tuple return values?

Question

I have just watched a video presenting the new features of C# 7. Among others, it introduces the possibility to return a tuple type (e.g.: (int, int), which, I believe, is just a syntactic sugar for Tuple<int, int>). Thus, if we have a method returning multiple values, there are 3 possibilities in C# on how to do it:

(int first, int second) ReturnTuple()
{
    return (1, 2);
}

int ReturnOutParam(out int second)
{
    second = 2;
    return 1;
}

CustomObject ReturnObject()
{
    return new CustomObject
    {
        First = 1,
        Second = 2
    };
}

I believe, there are no more ways to do it - if yes, please, correct me.

Which of those three methods is the right one? And in which cases can we use the remaining two? With every new C# release, I have the feeling that there are one or two design patterns that just became obsolete in the .NET world. Some features were very useful (like generics, partials, LINQ, lambdas, async/await or null propagator). Others are very situational (dynamic, nameof). And then there are those that just don't make sense to me (property auto-initializers, tuple return values or local functions).

Answer 1

First and foremost, a tuple like (int, int) is syntactic sugar for ValueTuple<int, int>. The differences between Tuple and ValueTuple are:

• ValueTuple is a value type, so there's no need to allocate an object on the heap
• ValueTuple is mutable
• ValueTuple has (obviously) built-in language support, and it lets you name the tuple items through a custom attribute (TupleElementNamesAttribute). With Tuple, you'll only get Item1, Item2 etc.

With each new language version some features become obsolete. For instance, the delegate { } syntax was superseded by lambdas. You could argue that out parameters fits in this category, but that's subjective. Yet all the features need to stay there for backwards compatibility.

For instance, bool int.TryParse(string input, out int value) should have become int? int.TryParse(string input) with the inclusion of nullable value types to the language, but the old function was already there in the framework, so it had to stay.

My rule of thumb would be: use value tuples for private methods or utility functions, but prefer full-fledged structs for any public API, it just feels cleaner this way. I generally avoid out params except occasionally for private methods.

I don't get why some of these new features don't make sense to you:

• Property auto-initializers are finally there, they should have been implemented along with auto-properties in the first place, but were probably skipped because of time constraints. It's an obvious win for code readability, and it adds a feature that was always there for fields.
• Tuple return values is the topic of your question, it's also an obvious readability win over the old tuples. Being able to name your tuple items speaks for itself.
• Local functions will mostly prove useful for implementing the iterator pattern, but I occasionally wished to have such a feature and worked around it by using a lambda.

Answer 2

For me it still depends on the situation. For example for TryParse it's still more readable to do:

if (int.TryParse("123", out var i))
{
   // i
}

than

var (success, i) = int.TryParse("123");
if (success)
{
   // i
}

and in most cases returning more than one value from method is a code smell. You should always wrap what you return into class which describes your values better than First and Second.