Collection expressions turn out to be evil in some scenarios.

[ScarletKuro]

There is a built-in analyzer IDE0300 that suggests replacing new [] {x, y} with just [x, y]. However, the code is not always equivalent to what you initially had.
For example:

public void M(IReadOnlyCollection<string> cards){
    // ...
}

public void Invoke()
{
    M(new string[] {"1", "2"}); // IDE suggests M(["1", "2"]);
}

The IDE suggests replacing it with M(["1", "2"]);, but this will silently generate an internal class <>z__ReadOnlyArray<T> that implements IReadOnlyCollection, which is not the same as the original code. Proof: SharpLab Link.

This becomes a problem if you're using RMI frameworks like Orleans, which will complain that such a type (<>z__ReadOnlyArray<T>) doesn’t exist.

So, I’m not sure why the analyzer suggests this replacement if the two forms are not equivalent, and it’s easy to make a mistake. I also don’t understand why Microsoft didn’t consider this edge case when implementing this feature.

[huoyaoyuan]

The analyzer rule IDE0300 is configurable in two modes: when_types_exactly_match and when_types_loosely_match. See the documentation at https://learn.microsoft.com/dotnet/fundamentals/code-analysis/style-rules/ide0300 .

when_types_exactly_match has the behavior you want. It won't suggest changes to the actual type created. when_types_loosely_match is set as the default because it's usually beneficial in more cases, but you can turn it off.

[ScarletKuro]

Thanks, I actually didn't pay attention to the options. That's very useful.