We probably won't switch to 4.7 at work for another year or so but this is probably the feature people on the floor are most excited about.

So does this mean the tuple preserves the type of its members unlike an object[]? What's a situation where you would want to take a collection of objects that don't even share a common interface? (Not bashing tuples, very curious about the benefits of this.)

Edit: I think I understand tuples when you're using them as return types like (MyClass class, Exception e), which can already be done with Tuples just without the nice syntax. But I'm confused about generically taking or returning an ITuple you know nothing about.

I've used tuples in the past when a method could fail and I want the error code back or I want the thing.

e.g.

(string errorCode, Quax result) TryGetAQuax();

Oh, to have Either / Discrimated Unions in C# :(

We also can't use this at work, we are still having to target 4.5.1 :(

> Oh, to have Either / Discrimated Unions in C# :(

Here you go: https://sourceforge.net/p/sasa/code/ci/dotnet-standard/tree/...

You can use it like:

    Either x = 99;
    if (x.TryCase1(out var s))
        ...
    else if (x.TryCase2(out var i))
        ...
Only up to 4 cases are included because beyond that, I think you should define a custom type.

Although I should note that C# now supports special casting via the 'is' operator, so you can now just do this:

    object x = 99;
    if (x is string s))
        ... do something with 's'
    else if (x is int i))
        ... do something with 'i'
There's also the OneOf NuGet package [1] which I've put to good use in a number of projects. Using `object` and `is` means you can't enforce what types get passed in, nor can you ensure that all possible types actually get handled.

[1]: https://github.com/mcintyre321/OneOf/