Hacker News Reader

Comment by bonoetmalo | Hacker News Reader

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.

View on HN

You don't have to use .NET 4.7 to get that feature. What you can do is to add a reference to System.ValueTuple NuGet package. Once added, value tuples are there to bring the goodies to your code and business.

Be careful, System.ValueTuple has a compiler requirement too.

So you are correct to say you don't need .Net 4.7, but you DO need a C# 7 compiler to use System.ValueTuple with .Net 4.5/4.6. We tried to use System.ValueTuple and it would work on VS 2017 but fails to build on VS 2015 due to compiler complaints.

We resolved this by adding the NuGet package "Microsoft.Net.Compilers" to the project. This results in a C# 7 compiler traveling with the solution, and no matter what Visual Studio/installed compiler you have it works.

This won't be a problem in the future as most project templates in Visual Studio come with Microsoft.Net.Compilers preinstalled. Only impacts older projects (such as those targeting .Net 4.5/4.6, etc).

The best usage I've seen for them so far is around intermediary LINQ query results. Usually you can use anonymous types, but sometimes you can't. It's a lot easier using tuples than having to add a little POCO class for something you don't really care about, or resorting to something ugly like the old Tuple type.

> What's a situation where you would want to take a collection of objects that don't even share a common interface?

I found myself in a situation exactly like this a while back.

I was given the job of figuring out how to validate data in various stages of an ETL pipeline. I ended up writing a Python program to do the work in a fairly configurable manner.

The key to this working was the fact that tuples in Python can be used as keys for a hash table and are comparable. The program would run different queries in different databases, split the results out into key and value tuples, use the key to store the value tuples in a hash table, and finally do some comparisons.

Since it was all driven by configuration, the code that did the comparison across couldn't know in advance what the data types were or how many columns were involved.

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 :(

Could you use the System.ValueTuple NuGet package?

Requires 4.6.1

Also works with .NET 4.5. System.ValueTuple package has .NET Standard 1.0 target which can be effortlessly used by a .NET 4.5 assembly.

You can :) (Especially with the pattern matching feature) https://github.com/louthy/language-ext

> 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<string, int> 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/

I can never justify the use of delegates for pattern matching purposes. It's just way too much overhead, and so would discourage the use of these abstractions.

> when a method could fail and I want the error code back or I want the thing

For this use case, I mostly use a Result<T> with .Status, .Messages, .Exception, .Data etc properties.

I hope someone could describe some good scenario. Maybe some low level data exchanges. Database connectors, interop with dynamic languages? Interfacing with hardware drivers? Piping some third party datasource to json where you don't care about types and number of arguments in backend?

Reply on news.ycombinator.com