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.

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.