This is not testing slice. Did you mean LengthPattern_Exhaustiveness #Resolved

new line #Resolved

📝 I'll have a PR out for this next (I'd probably hold that off until after LDM) #Resolved

Maybe also test for new C<Index>() is { 0 } with class C<T> { this[T] } (should work) #Resolved

Good idea. It looks like there may be a bug with Index/Range, and the same one for list patterns. See ListPattern_GenericIndexingParameter below.

I don't think this is intended to be here. #Resolved

Slice could return an arbitrary type - as far as the analysis goes, the input type of the subpattern is "unrelated" to the list. #Resolved

Right. I think there's still a question of whether we have some reasonable expectations when a slice returns an indexable/rangeable type. Do we just give up on analysis or do we have some notion of what is "well-behaved"?

We only do this for tests when the input is exactly the same. In #53891 I had to explicitly add a special case when there's two different but "matching" indexers as the input which is a little unorthodox.

As for slice subpatterns, it wouldn't be that simple. We should match nested subpattern with the outer list. I didn't go through it but I'd expect it's going to be a lot of work which is arguably unlikely to be useful in real code.

I'd expect it's going to be a lot of work which is arguably unlikely to be useful in real code.

I agree. I'd be comfortable dropping the slice analysis. Just need to confirm with LDM.

📝 We possibly can support this if we relax range indexers too. #Resolved

Assuming positive count in the codegen or for subsumption? e.g. Is the match e is [-1] impossible? of course we don't need to worry about this if we drop length patterns.. #Resolved

LDM agreed to make such assumptions for the length/list pattern. But not generally for property patterns such as Count: <= 0 above.
Not having a good syntax for empty list means causing more pain if I fall back to Count property pattern.

📝 Will be addressed by #53891 #Resolved

Very cool. Thanks!
Ping when you want some eyes on that PR.

I think we should also test for [ImplicitlyConvertibleFromIndex i] (should work) #Resolved

Good idea. Added ListPattern_ImplicitlyConvertibleFromIndexAndRange which hit an assertion.

This is expected. we require exactly this[int] as the member for implicit support (vs. only a viable lookup for Index). #Resolved

Perhaps we should open a tracking issue to make an analogous change for the scenarios @alrz is referring to.

nit: assert on declarations.Length? (same comment in the other similar new tests) #Resolved

nit: prefer PROTOTYPE(list-patterns) (also for other prototype comments in the file.)

FWIW, I don't see shortcomings in the pattern explainer as blocking.

Since we disallow the "PROTOTYPE" keyword in main branch, I figured the longer format doesn't help much (and it's more trouble to type). I'll stick with that if that's okay.