Hacker News Reader

Comment by thecopy | Hacker News Reader

Agreed! I really like the idea of symmetry when calling a method. I have never gotten why we can send multiple values in, but only one value out. And polluting the source code with structs for every method which needs to return two or more values is ugly.

View on HN

There have been Generic Tuples for a while in .NET... https://msdn.microsoft.com/en-us/library/system.tuple%28v=vs...

Those things suck. Every time I think about using them I always end up just using a dict or declaring a new struct.

Yeah I agree, having to keep in mind what you put into Item1, Item2, Item3 etc really isn't programmer friendly

F# uses them just fine and they don't suck. So perhaps it's just the compiler/language not dealing with them very well?

Edit: OK so it does suck that it's a reference type for even small tuples. But it's not C#/F#'s fault the CLR doesn't do a better job on those kinda things.

F# allows you to break up the tuple immediately, this tremendously aids readability as it avoids introducing confusing names.

    let (a, b) = Foo()

Compared to

    var tuple = Foo();
    var a = tuple.Item1;
    var b = tuple.Item2;

You could consider them equivalent, but conceptually it is faster to understand that a is the first result IMO.

I'm just pointing out that System.Tuple doesn't suck as the commenter was saying. It's just C#'s handling of them.

Given that the proposal specifically mentions using struct instead of class it isn't just C#'s handling that makes it difficult to leverage System.Tuple.

Funny, the BCL folks went with a class and we were assured it was a good decision. Maybe they just need to get their JIT up to date and do escape analysis so this kinda thing doesn't cost so much. (Easy for me to say they should do it...) After using Rust+LLVM I'm accustomed to the idea of not having to pay so much for features.

Which means they suck in C# doesn't it?

Well, that's what out and ref parameters are for

That's what C APIs look like. Sure it works, but it's not pretty. Conceptually, it makes sense to pass in an argument that gets modified (C# ref), but it's confusing and weird to have a parameter that's purely for output.

Except out and ref parameters are exactly zero fun to use. Wheras returning two values is a lot of fun, esp. with pattern matching.

This is somewhat subjective...

I'm not sure I find either more fun than the other.

You are absolutely correct. Perhaps fun is the wrong word. It is however, a royal pain to use the first, and way less so to use the second...That's something I feel I could probably defend in an objective sense.

The problem, and as far as I can tell the reason that they're considering a better tuple return value is that these don't work with async.

The existing tuple type doesn't work well because its members are generically named; and very few people want to make lots of little classes that are only used to pass results from one method to its callers.

Yes, at the cost of forcing the developer to start thinking in pointer semantics. When the language is trying to steer away from that, and suddenly introduces explicit attributes to return to that age, I think there's kind of a conflict polluting the language a little where it wouldn't have to be.

I do believe at least 'ref' should be in the language to simplify C/C++ interop, but I think it they should firmly nudge devs into thinking of that more as a convenience feature for .NET marshalling.

The beauty of tuples is that you get both a useful data type and nicer data passing in one bang with the tuple deconstructors, without requiring pointer semantics. Really a lot to win with just one concept.

Reply on news.ycombinator.com