ImmutableArrayExtensions and Enumerable parity

[alrz]

Right now ImmutableArrayExtensions only features a subset of linq methods, e.g. Join, SelectMany, etc are not present.

1. Is it possible to avoid boxing on IA<T> to IE<T> conversion in the runtime to directly use the underlying array (if this is not already the case)?
2. If not, is it feasible to add all the other missing operators from Enumerable?

[eiriktsarpalis]

We've generally resisted exposing full-blown Linq APIs for specific collection types, primarily because of the cost of maintenance and because chaining Linq methods in non-deferred types can be expensive. It doesn't seem to me that avoiding boxing on the source collection would outweight the costs of chaining non-deferred linq operations.

[stephentoub]

Theoretically, an ImmutableArray-specific iterator would avoid boxing to IList<T>

By the time we get into the LINQ methods, the IA<T> has already been boxed. Can you elaborate?

as well as all the virtual calls on the indexer

A key goal of dynamic PGO is to minimize/eliminate such overheads. This is why I'm interested in specific cases where these costs are viewed as prohibitive with IA<T>.

it's definitely preferable to porting the entire Linq API to ImmutableArrayExtensio

That's not something we're going to do.

[alrz]

To take the discussion away from linq-specific usage, I'd reiterate my question on the first point,

IEnumerable<T> seq = immutableArray;

Is it possible for the runtime to recognize this conversion and assign the underlying array to seq instead of a box?

[eiriktsarpalis]

What would happen if immutableArray was the default value? Would seq suddenly become null violating its nullability annotation?

[alrz]

I guess if the runtime is going to alter the boxing behavior, it could also handle the empty case? Also there's the question of unboxing, not sure if anyone do (IA)seq but that's probably where it becomes unfeasible. To avoid this I've added an Unsafe.As everywhere the boxing squiggle lights up for me which hurts readability at the very least.

Ideally using an immutable array shouldn't affect usage/runtime behavior compared to a plain array that you'd never write to.

In the past I've opened a discussion for immutable T[] support (dotnet/csharplang#421) but that didn't go anywhere.

[CyrusNajmabadi]

To take the discussion away from linq-specific usage, I'd reiterate my question on the first point,

IEnumerable<T> seq = immutableArray;

Is it possible for the runtime to recognize this conversion and assign the underlying array to seq instead of a box?

That would be unsafe. Someone could cast back to the underlying array and mutate it.