Extension methods aren't being factored into collection expressions

[stephentoub]

Version Used:
https://github.com/dotnet/roslyn/commits/e3cf188c71ec62089866f0e99bd535cd47878659

Steps to Reproduce:

U u = new();

List<T> list1 = [];
list1.Add(u); // works fine

List<T> list2 = [u]; // fails to compile with "Cannot implicitly convert type 'U' to 'T'"

class T;
class U;

class Adapter(U u) : T;

static class Extensions
{
    public static void Add(this List<T> list, U u) => list.Add(new Adapter(u));
}

Diagnostic Id:
CS0029

Expected Behavior:
Compiles

Actual Behavior:
Fails to compile

The spec seems to suggest this should work?
https://github.com/dotnet/csharplang/blob/main/proposals/csharp-12.0/collection-expressions.md
e.g. "If the collection expression has any elements, the type has an instance or extension method Add where: The method can be invoked with a single value argument"

[CyrusNajmabadi]

I read the spec here and it's... weird. This is all in the Conversions portion afaict.

We have one part which seems to allow this. But then another part that overrules it. Specifically, we start by saying:

If the collection expression has any elements, the type has an instance or extension method Add where:

• The method can be invoked with a single value argument.
• If the method is generic, the type arguments can be inferred from the collection and argument.
• The method is accessible at the location of the collection expression.

That would seem to allow this situation as we do have an extension method Add which can be invoked with a single value argument, which is non-generic, and which is accessible at the location of the collection expression.

However, a little further down we have:

The implicit conversion exists if the type has an element type T where for each element Eᵢ in the collection expression:

• If Eᵢ is an expression element, there is an implicit conversion from Eᵢ to T.

I'm not sure why we have this, and seems overly restrictive. It basically says that extensions exist and should be considered, but we will not actually look at their signatures to determine if the expressions are ok.

This is doubly weird as the following is legal List<T> list3 = new() {u};. Here we clearly do consider the 'extension Add' method and we then call into it.

[stephentoub]

@CyrusNajmabadi, also, this:

List<T> list1 = new();
list1.Add(u);

triggers IDE0028, which rewrites it to:

List<T> list1 = [u];

which fails to compile.

[jcouv]

Dug up more context:
The scenario above is the "Category 3" scenario described in this proposal: #8034
The proposal states that "Types in category 3 would still not be valid target types, unchanged from 17.8."
It looks like it was last discussed on April 17th 2024 (list of meeting notes)

[CyrusNajmabadi]

Oh ick. I remember now. This was because of:

M(u);
N(u);
void M(params T[] ts) { }
void N(params List<T> ts) { }

When doing params collections, we didn't like that we couldn't determine if it was ok at the reference site to make something params-collection or not. Instead, we wanted to know distinctly at the decl site. And we then didn't want that meaning to change at different locations.

So we removed the understanding of extensions from this space. Because of how params worked, and our desire to align collection expressions with params, we then lost that capability there too :(