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

[douche]

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.