List pattern indexer resolution problematic

[elgonzo]

(My apologies if this already has its own topic elsewhere. Github's search function making it hard to search for phrases and not just words made it difficult for me to check if there already exist such a topic, given that words like "list" and "pattern" occur in countless topics here...)

For the list pattern, the rules the compiler follows to pick an indexer are currently as follows (https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-11.0/list-patterns):

A list_pattern is compatible with any type that is countable as well as indexable — it has an accessible indexer that takes an Index as an argument or otherwise an accessible indexer with a single int parameter. If both indexers are present, the former is preferred.

A slice_pattern with a subpattern is compatible with any type that is countable as well as sliceable — it has an accessible indexer that takes a Range as an argument or otherwise an accessible Slice method with two int parameters. If both are present, the former is preferred.

If a type features both an object-based indexer together with int-based indexer and/or a Slice(int start, int length) method, the compiler will pick the object-based indexer and passes a boxed Index or Range instead of using the int-based indexer or the Slice method.

This is problematic because this rule is reliant on the bold assumption that the object-based indexer will just do the right thing expected by the list pattern despite there being an int-based indexer and/or Slice method that wouldn't require such assumptions. Not even to mention the mystery of what the return type of such an object-based indexer is supposed to be when it has to return both single values (Index) and a set of values (Range). This makes it basically impossible to use existing types that implement both such indexers (and possibly a Slice method) together with the list pattern and slice pattern, despite those types having everything necessary to support either the list pattern or slice pattern. Case in point (with respect to the list pattern): Newtonsoft.Json's JArray type. See also the discussion here: #8535 (reply in thread).

I therefore propose to change the rules to:

A list_pattern is compatible with any type that is countable as well as indexable — it has an accessible indexer with a single Index parameter or otherwise an accessible indexer with a single int parameter. If both indexers are present, the former is preferred.

A slice_pattern with a subpattern is compatible with any type that is countable as well as sliceable — it has an accessible indexer with a single Range parameter or otherwise an accessible Slice method with two int parameters. If both are present, the former is preferred.

and adopt the compiler behavior accordingly.

[CyrusNajmabadi]

Those apis should be updated to support Index.

[elgonzo]

The list/slice pattern shouldn't make bold assumptions about implementations of object-based indexers to begin with and therefore not try to use them, especially if there is an int-based indexer and/or a Slice method present that suit the list pattern and/or slice pattern just fine...

[333fred]

This honestly just seems like a compiler bug. I don't think the spec needs to change.

[elgonzo]

As it turns out (discussed in a different topic), the list pattern follows the already established precedent where for example using an index like [^1] would also call the object-based indexer but not the int-based indexer. I have no broader insight into the wider .NET ecosystem and developer community, and what it would effect if features like these were tidied up to make their behavior seem less surprising and arbitrary, so i leave it to the team what to do about it. Or likely not to do, considering that Index and Range are around already since the Core 3.0 days (and so is quite likely the behavior of favoring object-based indexers for them). While i have to admit that on a personal level i am not happy about the current behavior, i at least came to understand the rationale behind it.