Collection Literals and Constructor Parameters

[TonyValenti]

Hi C# team:
I use HashSet and dictionaries s a lot in my code and would love to be able to use them with collection literals. They work great when I don't need an IComparer<T> but once I do, I can't use them.

I want to throw out an idea on how IComparers could be used.

Allow calls with a syntax like one of the following:
Option 1: Test(["1", "2", "3"] with { comparer = StringComparer.InvariantCulture, });
Option 2: Test(using { comparer = StringComparer.InvariantCulture} ["1", "2", "3"]);
Option 3: Test(with { comparer = StringComparer.InvariantCulture} ["1", "2", "3"]);

(Option 3 is my preference)

In the code above, with/using means "When selecting the constructor for the specified collection literal, the constructor that is selected by the compiler must have a parameter named comparer which is compatible with the value provided. In the event that multiple constructors meet all of the specified criteria, the compiler is free to pick any of the available constructors." The syntax would essentially be like partially specifying a PowerShell argset. Also, while I might only be specifying the comparer argument, any number of constructor parameters could be specified.

[HaloFour]

Doesn't seem to be much of a difference using existing syntax with target-typed new:

Test(new(StringComparer. InvariantCulture) { "a", "b", "c"} );

[TonyValenti]

You are correct but my understanding is that the collection initializers are not gaining all the performance enhancements made for collection literals.

[KennethHoff]

In addition to what Tony's saying; some collections - like immutable arrays - literally don't work with initilizers.

[qrli]

For those collections with constructor taking an initialization collection, such as HashSet, the following also works:

Test(new(["a", "b", "c"], StringComparer.InvariantCulture) );

[ufcpp]

If we were talking only about collection expressions, I would be against this idea, but if it could be used for string interpolation culture propagation, etc., it might be a little more appealing.

[jnm2]

I don't share the full position here, but I do find the extension to interpolated strings interesting. Only thing is that the interpolated string case can be a simple API without language support.

[jnm2]

with { capacity = 42 } could help in those situations where the collection will be modified after construction and there's no way for the compiler to plan for that.

[qrli]

Why not just enable collection literal in the position of initializer?

Test(new(StringComparer.InvariantCulture) [ "a", "b", "c" ] );

[HaloFour]

The following syntax is already legal, as you can immediately index off of a construction expression:

var x = new Foo("bar") [ 1, 2, 3 ];

You can argue that such syntax does not work with target-typed new, but I would not expect omitting the type name to drastically change the behavior.

[qrli]

My key point is that: rather than introducing new syntax at the constructor parameter side (where it can be much more complicated), it is better to do something at the position of initializer. The syntax is up to discussion. E.g. a silly idea:

Test(new(StringComparer.InvariantCulture) using [ "a", "b", "c" ] );

[TahirAhmadov]

@qrli what if the target type is IEnumerable<T>, then new(...) doesn't make sense, so C# has to do a look-ahead, which is more complicated than it needs to be.

[qrli]

what if the target type is IEnumerable, then new(...) doesn't make sense,

In that case, there is no need for extra parameters to pass.

[TahirAhmadov]

True, there is no need, but the language still needs to handle this from interpreting the tokens perspective, which adds complexity.

[iam3yal]

Another alternative that might work is pass the arguments to the constructor as part of the collection expression itself so something like this:

[(StringComparer.InvariantCulture), "1", "2", "3"]

I'm not sure whether it's confusing so maybe something like this:

[(StringComparer.InvariantCulture), ["a", "b", "c"]]

[CyrusNajmabadi]

It feels to me that the easy way to do this will just be extension methods on collection literals, which we want to do in c#13.

So you'd just do [x, y, ..z].ToSet(comparer). Simple, clean, readable. Performance would normally be good, with stack allocing the temp values to pass in, etc.

This feels like a "good enough" solution to this corner case.

[HaloFour]

It feels to me that the easy way to do this will just be extension methods on collection literals

Has the added benefit that the extension methods could be intentionally written to support collection literals, whereas some constructors probably don't make a lot of sense.

[iam3yal]

What is the syntax? something like this ToSet(this [] source, ...)?

[HaloFour]

I think the type would be Span<T> or ReadOnlySpan<T>?

[iam3yal]

ahh right! makes sense.