Hacker News Reader

Hacker News

Comment by joshschreuder | Hacker News Reader

Parent Full thread

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.

View on HN

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