IDE0028 raised erroneously for collection type with Add(T) and IEnumerable<T[]>

[stephentoub]

Version Used:
Version 17.11.0 Preview 1.0 [34804.211.main]

Steps to Reproduce:

using System.Collections;

MyCollection<object> c = new() { "Hello" };

class MyCollection<T> : IEnumerable<T[]>
{
    public void Add(T item) { }
    public IEnumerator<T[]> GetEnumerator() => throw new NotImplementedException();
    IEnumerator IEnumerable.GetEnumerator() => GetEnumerator();
}

Diagnostic Id:
IDE0028

Expected Behavior:
No diagnostics.

Actual Behavior:
IDE0028 triggers and the fixer rewrites the new() { "Hello" } to be ["Hello"], which then fails to compile with error CS0029: Cannot implicitly convert type 'string' to 'object[]'.

cc: @CyrusNajmabadi

[CyrusNajmabadi]

@stephentoub do you have a real world example of this? We're aware of TheoryData, but we're trying to collect a list of all these types to help with future lang design. Thanks!

[stephentoub]

TheoryData :)

[CyrusNajmabadi]

@stephentoub Perfect. I'll let @cston dupe this as something known. We are working on this. If you run into other real-world apis, def let us know as we want any changes here to work for all of them. Thanks!

[cston]

Collection expression conversions require the elements to be implicitly convertible to the collection iteration type. That requirement still holds in the latest proposal for target types that implement IEnumerable and do not use [CollectionBuilder] (see category 3 in dotnet/csharplang#8034). That will limit use of Xunit.TheoryData<T> with collection expressions to cases where T is implicitly convertible to object[].

[cremor]

#73655 seems to be related to this and contains a real world example with the FluentValidation library.

[cston]

In the repro, the compiler is behaving as expected reporting an error for c = ["Hello"] since string is not implicitly convertible to the collection iteration type object[].

Reassigning to @CyrusNajmabadi since the original diagnostic IDE0028 is reported from the analyzer.