NamedValueTuple and params keyword

[Acerby]

I find ValueTuple a great way to pass lists of values to a function without them being boxed eg:

void myFunction(string message,T args) where T: ITuple
{
if(notNeeded)return;
//... handle args possibly boxing them here if needed.
var item1=args.item[0];
// assuming a nice extension function to make a IEnumerable from the ITuple
var argsArray=args.itemsAsEnumerableOfObject().ToArray();
}

the params keyword

It would be grate if we could use the params keyword with the above such that it meant the values appeared in line eg:

void myFunction(string message,params T args) where T: ITuple
{ ... }
myFunction("message",1,2,3);
ie the complier would add support for the params keyword being used with a single Tuple type argument in this way.

passing named parameters

Sometimes it would be useful to pass named arguments to a function this could be achieved by introducing NameValueTuple type.
The NameValueTuple type would hold a set of KeyValue pairs such that the key was a string representing the argument name, and the value would hold the original typed value of the argument given. ie it would be a generic based on value types, like the pre-existing ValueTuple type. The compiler would then support an implicit conversion of a pre-existing ValueTuple to a NameValueTuple based on the implict names it currently "knows" for the ValueTuple type.

We could then have a function as follows:

void myFunction(string message,T args) where T: INameValueTuple
if(notNeeded)return;
//... handle args possibly boxing them here if needed.
KeyValuePair<string,object> item1=args.item[0];
// assuming a nice extension function to make a IEnumerable<KeyValuePair<stirng,object> from the INameValueTuple
var argsDictionary=args.itemsAsEnumerableOfObject().ToDictionary();

var d=7;
var e=8;
var s="444"
myFunction("message",(d,e,s));
(string a,int b) retVal=anotherFn(...)
myFunction("message",retVal);

[HaloFour]

What use case does this have? Given you'd have very limited ways of interacting with those tuples within the method, it would seem that you can't avoid allocations and a lot of overhead simply navigating the values.

[Acerby]

If by "already has features..." you mean that I could avoid boxing for a function that accepts a number of arguments by creating overloads for all the various combinations of arguments that I wanted to support then yes I agree. But my understanding of the params keyword is that is designed to avoid the need for you to create overloads for all the combinations you want to support. The params indicates you want to be flexible with regards to the number (and prossibly types) of arguments supplied. The use of a ValueTuple seems to best way to currently represent a ordered set of values that can be of any type, and doing so without requiring additional allocation/boxing.
But maybe I am missing something?

[theunrepentantgeek]

The use of a ValueTuple seems to best way to currently represent a ordered set of values that can be of any type, and doing so without requiring additional allocation/boxing.

A tuple (value or otherwise) is a lightweight ephemeral way to group a set of related values together. There's nothing ordered about them, and nothing set-like either.

If you want an ordered sequence of values, use a span or a list or an array.

Using a tuple is like using a chisel as a screwdriver - it might get the job done, but when things go wrong it'll be messy. The solution isn't to make the chisel into a better screwdriver, it's to use the right tool - the right abstraction - for the job.

[HaloFour]

You can use a span to pass a set of values to a method without allocation.

I still don't see how you would write a method to accept an arbitrary tuple of any unknown values without allocations/boxing required to negotiate those values. I suspect any savings attempting to avoid an allocation would be lost several times over. Not to mention, passing large value types is more expensive than an allocation.

[Acerby]

I totally agree that if you know in advance that you wish to work with a set of a know type, eg a list of decimals, then a span is a much nicer approach than a tuple. The advantage of tuples comes when you dont know the types of items being processed in advance, or you need a set of items including different types.
To give you an example of why tuples might be good, you code for example, look on utube for videos about high-performance logging. You will note that they often suggest that to avoid the problems of using object[] based params, that you make additional overloads with various numbers of generic parameters avoid performance issues, and then use the params like overload as a fallback. This is a clear example of where they want to support of handling variable number of unknown types at run-time in an efficient manner.

[HaloFour]

To give you an example of why tuples might be good, you code for example, look on utube for videos about high-performance logging. You will note that they often suggest that to avoid the problems of using object[] based params, that you make additional overloads with various numbers of generic parameters avoid performance issues, and then use the params like overload as a fallback. This is a clear example of where they want to support of handling variable number of unknown types at run-time in an efficient manner.

Or use a custom string interpolation handler, which was designed to do that job. Or use an args supplier lambda, which was the idiomatic way to handle that before custom string interpolation.

Having to handle an unknown number of types and names at runtime won't be efficient. What you gain in some language feature to pass the data will be lost in negotiating that data, including in terms of allocations.

[HaloFour]

It's possible that with params collections you'll end up with a syntax that would work very similarly to this. GIven collection expressions are also exploring dictionary expressions, that would potentially give you the named version also.

[Acerby]

Yes totally, and that would be great. However its also possible that they will assume all the supplied arguments are of the same type, and require they are boxed into a list/collection. My point here is that value-tuples already pre-exist so this is low-cost to implement and gives high benefits. So C# already has syntax for this and ways to represent it. Also this would for example support json like scenarios, whereby a given multiple parameters can have the same name, whereas requiring a dictionary based approach would not only require a large amount of allocation/boxing and be more limited in functionality.
To be clear I hope they support multiple target types for params, with this just being one option. If they initially hold data in named tuples which require no boxing/heap-allocation, then supporting other target types for the params arg such as dictionary targets is then straightforward and they wouldn't need to create a total new/different syntax for it from what the language already supports.

[Acerby]

Many thanks for all the feedback. On reflection I think I should have perhaps presented this slightly differently as follows:

Currently we have a construct like params object[] args
In many ways it initially appears to reflect give us total flexibility which is great. However there are in practice there some issues with this:

1. In some cases we might like to be able to restrict the type to something more-specific so-as to enable better compile time warnings.
   For example we might want to support just a list of strings or int's, and warnings for when its passed non-string/int like objects.

2. Whilst "object" supports all types in practice value-type things cant be represented as-is, instead they need to be boxed (and put on the heap). Whilst this can be fine for many scenarios. For performance-critical calls this can represent a significant problem.

3. Having a return type be an array also implies the requirement to make an object on the heap to hold the values, with similar performance affects to item 2 above.

Later versions of .net support a Span type construct that would be great for all the above issues where the type T is the same for all items in the params as it avoids any need to box or put items on the heap. However this doesn't support the flexibility of the original object array return type, in that it requires all parameters to be of the same type. That's less of a problem if class/reference type objects as we simply specify object or some base class/interface. But it is a problem for value-types because they don't have a common type except object, which has the issues mentioned above.

Ideally it would be nice to be able to have something like a Span<*> which would support any type of argument with-out boxing etc. However there is no easy way to produce such a type from practical viewpoint, and adding such a thing to the language would almost certainly be prohibitively expensive. However from a practical point of view we do already have a pre-existing ValueTuple type construct that already exists in the language and uses generics to support holding a set of values of any type. This gives (very nearly) all the functionality we are after and avoids boxing. If you were to imagine the ValueTuple type that supported a method that returned an IEnumerable or better still a Span then you could imagine you could have a method a bit like:
void MyFn<T>(string message,params T args) where T:IEnumerable<object>(....) which could then be invoked like: MyFn("MyMessage", 4, 3.5, myThing); // assuming the type T was somehow inferred in this scenario.
Of course currently that means boxing all the args and also creating a new array.
Now look imaging this:
MyFn("MyMessage",(4, 3.5, myThing)) // Now the brackets here create a ValueTuple (with no boxing required) -- and thus T becomes the type of ValueTuple created. Now if the compiler was told T was a ValueTuple and had a rule that in that scenario the extra brackets where nor required then we could simply have: MyFn("MyMessage", 4 ,3.5 ,myThing);
Now that looks exactly like we want, and allows us to use pre-existing types and requires only minimal changes to existing supported functionality, so should hopefully be reasonable quick/easy to implement.

Now there are a couple of details about the above that I did skip-over/simplify in the above:

1. You will note that in my declaration it specifies T:IEnumerable but the compiler would need to know to use ValueTuple type.
   One option would be to specify T:ITuple or something like that, and have it infer it automatically.
2. ValueTuple doesn't currently support IEnumerable although its a trivial to make an extension function for it that does.
3. It feels like a Span rather would be better than an IEnumerable, however that's probably impracticable without significant downsides.
   Additionally one of the primary reasons span's are preferred to enumerables is to remove the need to create an object on the heap to implement IEnumerable. However in this case the MyFn method actually "knows" the type of T and it IS a ValueType so it will build a specific version of the code for the supplied generic type and the compiler already has (I believe) logic to support efficient enumeration using value-based enumerators ie potentially enabling it to optimize-away the need to box the tuple in order to enumerate it.
4. Currently we will by default still (by-default) be boxing the Tuple items to objects if/when we use the enumerator to access them.
   In most cases this will not be an issue because we generally only need ultra-high-performance for when the function effectively does nothing eg. when logging is disabled, and we already need to accept lesser performance if/when we need to use the params supplied.
   Additionally for cases where we really need to avoid boxing, the implementation of MyFn could be written check to see if the supplied object was a ValueTuple and if so, then switch to a more-intelligent way of accessing the underlying objects without the need to box them. Its true such logic is currently non-trivial, but it would be rarely be required in practice, its not excessively complex, and could reasonably added as an efficiency improvement at a later date in the event performance testing indicated it would be beneficial, without impacting the functions calling signature.

[theunrepentantgeek]

Don't fall for the fallacy that the reason people disagree with you is that they don't understand what you're asking for.

Your original explanation was clear enough. By and large the people participating here are very smart.

Explaining the same idea over and over isn't going to change opinions.

[HaloFour]

It feels incredibly niche and trying to solve for the wrong side of the equation. Passing the tuple is easy and cheap. So is passing a normal struct. But if the consuming method is completely agnostic as to the schema of same type, any potential gains are already out the window. And this proposal doesn't attempt to address that at all. The only way to efficiently consume the type is to pass it to a generic method that accepts the actual type as a generic type parameter, and intentionally interacts with that type. But that's already perfectly legal in C# today.

[HaloFour]

TL;DR: this is already legal today:

public void M<T>(T tuple) where T: struct, ITuple {
}
    
public void N() {
    M((a: 1, b: "foo"));
}

Eliminating one set of parenthesis doesn't buy the programmer anything, nor does it make authoring a method that receives such a thing any easier to write or behave more performantly. Without a method to address the latter, the former seems unnecessary.

[GabeSchaffer]

The problem you have to overcome here is boxing when the callee doesn't know the types or number of its arguments. For example, you can declare a generic function that takes an ITuple (see HaloFour's post above), but then you can't get the items out of the tuple without boxing. At this point you're in the same place as if you had params ReadOnlySpan<object>.

I think that to make your request feasible, you'd have to propose a solution that makes the elements usable without boxing.

This is handled by the C# compiler for string interpolation by lowering to a sequence of method calls, with each argument being passed to its own overload of a method of a builder object. You can do this right now by abusing string interpolation (see https://sharplab.io/#gist:aa76f5ab0da5338a65d683e4e9f24215), but it's ugly.

This is handled in C++ with parameter packs (see https://en.cppreference.com/w/cpp/language/parameter_pack). When you want to iterate over a list of heterogeneous arguments of unknown type, you have to use either a fold expression or recursion. These options work OK for C++ because templates are expanded at compile time. To make this efficient in C# the JIT would probably have to unroll the loops or expand the recursion inline.