Hacker News Reader

Comment by gsmethells | Hacker News Reader

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

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.

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.

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).

> 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.

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.

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.

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.

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.

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

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

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

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.

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

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

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.).

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

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

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

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.

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

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

Type inference FTW.

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

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

Edit: Clarity

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

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; }
    }

Not quite equivalent, since System.Tuple is immutable. So, at minimum:

  public class Complex {
    private readonly double _i;
    private readonly double _j;
    public double I {get {return _i;}}
    public double J {get{return _j;}}
    public Complex(double i, double j){
      _i = i;
      _j = j;
    }
  }

But System.Tuple is also IComparable, IStructuralComparable, IStructuralEquatable. I haven't had enough coffee yet to add all the boilerplate for that to the above, which only reinforces the point about verbosity.

Although with c# 6.0 (current release) you can simplify that to:

  public class Complex {
    public double I { get; } 
    public double J { get; }
    public Complex(double i, double j) {
      I = i;
      J = j;
    }
  }

Even before C# 6.0, you could simplify it this way:

  public class Complex {
    public double I { get; private set; } 
    public double J { get; private set; }
    public Complex(double i, double j) {
      I = i;
      J = j;
    }
  }

Reply on news.ycombinator.com