params TCollection<T>

[TonyValenti]

Hi All,
I've seen different requests for params IEnumerable and such and I had a though I wanted to share.
Right now params requires a single dimension array. What if Params would allow any type with a default constructor and collection initializer method/extension methods?

private void MyMethod(params List<int> Items){ ... }

MyMethod(1,2,3,4,5);

Could be transformed by the compiler into:

MyMethod(new List<int>(){
  1,2,3,4,5
});

This would basically give people the ability to determine the type of params they want. LinkedList, List, HashSet, etc.

UPDATED 2022-10-07
In the event that params IEnumerable<T> is specified, the compiler will be free to select the type used to construct the enumerable.

#1366
#619
#1757
#178

[YairHalberstadt]

How would you create a params of an interface. Specifically IEnumerable?

[wdnijdam]

It may be better to get rid of params completely and use index brackets: #7843

[TonyValenti]

UPDATED 2022-10-07
In the event that params IEnumerable is specified, the compiler will be free to select the type used to construct the enumerable.

ORIGINAL RESPONSE
@YairHalberstadt Because interfaces are not types, you cannot create them. This is no different than everywhere else in the framework. That's why you specifically provide a concrete type that implements your ideal preference of IEnumerable.

So, depending on your situation, you might want to do any of the following:

private void MyMethod(params List<int> Items){ ... }
private void MyMethod(params LinkedList<int> Items){ ... }
private void MyMethod(params HashSet<int> Items){ ... }

In all three of those situations, Items is IEnumerable and it gives me the advantage of being able to pick the specific implementation of IEnumerable that best fits my needs.

[YairHalberstadt]

@TonyValenti
But what if I want to accept any IEnumerable in my method, or allow the user to use params?

That would be the advantage of allowing params IEnumerable instead.

I do like your proposal, and I think it is probably better than allowing IEnumerable params, I'm just raising a potential limitation with it.

[bbarry]

A method shouldn't dictate the concrete type of parameters that it is using though beyond what is necessary to implement the algorithm that the method is encapsulating. And that encapsulation never includes the construction of the parameter because that happens outside of the method call.

[YairHalberstadt]

A method shouldn't dictate the concrete type of parameters that it is using though beyond what is necessary to implement the algorithm that the method is encapsulating. And that encapsulation never includes the construction of the parameter because that happens outside of the method call.

Meh

That's more of a heuristic than a hard and fast rule. Over here I think there is very little harm that would cause, and the benefit outways any code purity concerns I have.

[TonyValenti]

@bbarry, while I do agree with you, params functions differently than most because, in its current implementation, params is a shortcut for new[] { ... } . Currently, you still have to specify the type, however, presently, the only available type is an array.

@YairHalberstadt
I'm not sure what you mean by 'allow the user to use params'.

If I have:

private void MyMethod(params HashSet<int> Items){ ... }

I should still be able to call it using any of the following methods:

MyMethod();
MyMethod(1,2,3,1,2,3,1,2,3,4); //Note that this would collapse to 1,2,3,4 since I'm backing with a hashset.  Cool!)
MyMethod(new HashSet<int>(){1,2,3});

I do suppose that it could be agreed that something like:

private void MyMethod(params IEnumerable<int> Items){ ... }

Would result in a call-site transformation to List if the 'params' items are listed.
For example:

private void MyMethod(params IEnumerable<int> Items){ ... }

MyMethod(1,2,3,4,5);
//Becomes MyMethod(new List<int>(){1,2,3,4,5});

MyMethod(new HashSet<int>(){1,2,3,4,5});
//Stays the same.

[YairHalberstadt]

Also not that params T[] would be inconsistent, as it doesn't have a default constructor, nor a usable add method.

However I don't think that's a genuine issue, as it's already special cased for collection initialisers.

[bartdesmet]

Also linking #179 which has a link to a proposal for a builder pattern to construct params collections. This can help to construct types such as ImmutableArray<T> more efficiently, by leveraging the compile-time knowledge of the length and by emitting calls against a builder pattern that can avoid copies. In a way, it goes beyond just calling Add for initializers, which are subject to dynamic resizing of the collection. E.g. constructing a List<T> using params would benefit from getting the length fed in to the capacity parameter on the constructor.

[SilentSin]

It gets a bit verbose, but the params keyword could take a type in the same way default does:

private void MyMethod(params(List<int>) IEnumerable<int> Items){ ... }

That would allow you to pick the most efficient enumerable type for your particular algorithm rather than always using the same default. Users could even consider that as a useful hint on which type works best with your method in case they are constructing their own collection.

[HaloFour]

@SilentSin

What collection would be more efficient than an array? Per #179 that's what the client would generate. Your suggestion would make the feature vastly more complicated and I don't see any benefit to it.

[333fred]

Converting to a discussion. This should be considered as part of #179.