Collection literals - passing round IReadOnlyList types for perf benefits?

[mungojam]

A random thought on the way that collection literals will create a new unspeakable type for readonly interfaces

If we created a simple function with the purpose of getting us an instance of the new type:

static IReadOnlyList GetFancyType(IReadOnlyList list) => list;

And then I used it whenever creating a collection:

var someCollection = GetFancyType([1, 2, 3]);

Would I end up with a type with better performance than ImmutableArray under any/some/all conditions?

Just interested really

[CyrusNajmabadi]

Yes. There are potentially some circumstances where this would be better in some metrics. For example, you might imagine an impl that special cases read-only lists of small sizes, inlining the elements directly into the result. This would be lower in size than an IMmutableArray.

That said, IMO, ImmutableArray would likely still be better in other ways. For example, accessing elements happens without the need for interface dispatch with an ImmutableArray.

Overall though, the point is that you choose the right type for your case, and we pick the right impl and construction strategy, so you don't have to.

Note: IREadOnlyList is also superior if you want the flexibility to change out the impl in the future. But that flexibility comes with the cost of interfaces. So this is ultimately up to you and your needs.

[jnm2]

Because collection expressions don't have a natural type in C# 12, the compiler won't be able to infer TList in that example. (I'm not even sure it would be able to infer both type arguments at once even if collection expressions had a natural type.) The spec won't allow the compiler to expose the synthesized type by using it as a type argument; the most information you'll ever have statically is the fact that it's some IReadOnlyList<T>.

[sab39]

Am I reading the spec right that we aren't getting [1, 2, 3].AsImmutableArray() with extension methods in C#12? Is that still potentially under consideration for C#13?

[CyrusNajmabadi]

Is that still potentially under consideration for C#13?

Yes, that is under consideration for C# 13. Ideally through a broadening where extension methods are applicable on an expression, not just a type.

[FaustVX]

@CyrusNajmabadi

where extension methods are applicable on an expression, not just a type.

Wow, I didn't see that.
Where can I learn more about that ?

[CyrusNajmabadi]

It's just somethign we're bandying around. Effectively, shifting extension methods to always have the logic that you can write expr.ExtMethod(...) if it was legal to write ExtensionClass.ExtMethod(expr, ...).

note: it won't be as simple as that because of compat. But it's an interesting space, and it's possible that 'extension everything' may help motivate it more.

[jnm2]

@mungojam Creating a function allows you to infer the element type, but you can also do the same thing without a method call by writing (IReadOnlyList<int>)[1, 2, 3] if you don't mind explicitly writing out the element type.

There's been some interest in a future language feature down the road where you could explicitly infer type arguments, and then you could likely write (IReadOnlyList<_>)[1, 2, 3].

[mungojam]

Thanks, in my setting I'm after consistency across many repos and making it as easy as possible for people to achieve that even if they don't understand the ins and outs. I think it would be easier for me to say wrap a collection literal in a short function, than have people need to cast or declare the type instead of using var that we use everywhere else.

I haven't historically pushed to use IReadOnlyList for parameters, but wondering whether I might start to after this release

[mungojam]

I guess the linq specialisations for ImmutableArray would never get implemented for an unspeakable type unless it could be done with some compiler magic or source generators or something

[CyrusNajmabadi]

I guess the linq specialisations for ImmutableArray would never get implemented for an unspeakable type

The linq specialisations would work. linq looks for IList<T> impls, and these will implement that interface exactly so that these perf benefits can be had.

[jnm2]

That's right, the synthesized type would only be able to implement public BCL interfaces (such as IList<T>, which is part of the story of lighting up LINQ optimizations).

Even so, I don't expect to personally switch back to IReadOnlyList<T> from ImmutableArray<T> for passing between decoupled areas. Optimizations could change from version to version of the platform and SDK and chasing them before the need is proven seems like it could risk stealing attention. But I'll keep an open mind too.

[jnm2]

I'm actually not finding any LINQ optimizations for ImmutableArray<T> besides the IList<T> one. Do you know of any?

[mungojam]

I actually meant these ones which are ImmutableArray specific, though they didn't cover my Select((x,i) => ...) case the other day but it didn't matter

https://learn.microsoft.com/en-us/dotnet/api/system.linq.immutablearrayextensions?view=net-7.0

[jnm2]

This is good to keep in mind. Perhaps there will be a way for the compiler, framework, and JIT to conspire to expose T[] or List<T> wrapped by the synthesized IReadOnlyList<T> directly to LINQ methods the same way that ImmutableArrayExtensions exposes the wrapped T[] to them.