[gsmethells]

Feels kinda crazy to see tuples and pattern matching "just arrive" when other languages have had them for years.

[int_19h]

What's your bar for "other language"? Remember that C# is a mainstream language, with all that entails in terms of stability and conservatism of language design (and the other way around - it's popular partly because it's conservative). Comparable languages are Java, C++ and the like; and in that category, C# is, generally speaking, more on the "progressive" end of the spectrum. Comparing it to something like Scala is rather apples and oranges.

[contextfree]

A big advantage of this design over most of the other languages with tuples that I've seen is that their members can have names - that is, types can be anonymous but have named members. This I think hits a sweet spot as it's rare to not want fields to have names, but fairly common to want intermediate types that just bundle a few fields together where there's no good name that clarifies much.

[Retra]

Anonymous items with named fields are always only just one name away from being structs. That seems to me to be the least-sweet spot in the possibilities of (named/anonymous item) x (named/anonymous fields).

[int_19h]

It's a very big step in a language with nominal typing. Tuples with named fields are compatible (even across assemblies, if I remember correctly) so long as order, names and types match. Structs are not compatible in that manner.

[Digit-Al]

Nice point. There's also the fact that with deconstruction being added as well, you don't even have to have the overhead of declaring a struct variable to get the return value and then dereferencing the fields, you can just deconstruct the tuple into variable if you so wish.

[vyrotek]

> Anonymous items with named fields are always only just one name away from being structs.

That's a huge line to cross though! Once you give it a name then you generally have to give it a home somewhere.

[Sanddancer]

Out variables, and I imagine the various sorts of tuples, are created on the stack. Structs can by stack-allocated, or they can be heap-allocated, which has performance considerations which may be important in a given program. This feels much more like a case of right tool for the job than anything else.

[manigandham]

Every language has something missing, but C# has plenty of other great features so tuples weren't really that big of a problem. There are also plenty of built-in containers like the Tuple class that can offer the same functionality.

[cm2187]

Exactly. The biggest that comes to my mind is generics which are missing from many languages.

[MichaelGG]

A tuple struct fills nearly zero of the real use cases for language level tuples. No pattern matching makes it sort of useless.

[adwn]

What about returning multiple values from a function without declaring a dedicated type? That is pretty useful.

[rco8786]

Sure. Like how streams "just arrived" in Java yet C# has had the equivalent for years.

No language has every feature. C# is making enormous strides ahead of many of its counterparts.

[jinst8gmi]

Java's a pretty extreme outlier for late or non-adoption of modern features, but it is true that Java is the closest direct competitor/peer to C# in terms of usage/marketshare. C# seems to be steadily shifting from being a language which initially (v1.0) looked like Java to one which looks increasingly like Scala (e.g. addition of pattern matching, tuples, local methods etc.).

[codesterling]

Java is generally C#'s main competitor. Comparing them is the most appropriate comparison.

[premium-concern]

Scala seems to be vastly more expressive while simultaneously having only 20% of C#'s feature set.

[Newtopian]

F# would probably be a better comparison peer to Scala than C# would IMHO

[guiomie]

There was always the Tuple class you could use since .Net 4.

https://msdn.microsoft.com/en-us/library/system.tuple(v=vs.1...

[joshschreuder]

There's a few downsides to the Tuple class as mentioned here: https://github.com/dotnet/roslyn/issues/347

Namely, heap allocation and the inability to name tuple members.

[cm2187]

And a very verbose syntax. You have to repeat everywhere the different types of the different members.

[ojanik]

Tuple.Create(3, "hello", true)

Type inference FTW.

[andyjohnson0]

I find that the verbosity can be minimised by type aliasing. E.g:

using Complex = System.Tuple<double, double>;

Edit: Clarity

[cm2187]

But then you might as well declare a class or structure to store the data. The point of tuples is to be self-contained.

[andyjohnson0]

It maybe wasn't clear, but I was referring to the parent's point about verbosity when using the 'old' Tuple class.

    using Complex = System.Tuple<double, double>;

is less verbose than

    public class Complex
    {
        public double i { get; set; }
        public double j { get; set; }
    }