Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

We won't be able to merge this until the C# compiler is updated to guard overload resolution with params span on LangVersion.

/azp run

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

@jozkee, why did you mark this as breaking? What is breaking about it?

source breaking?

Can you elaborate?

There's a case where a collection expression can't resolve between ROS<string> and ROS<object>, see dotnet/sdk#41089 (comment). It may be a compiler bug, though.

Additionally, do we not want to document cases of types with conditions similar to StringValues?

There's a case where a collection expression can't resolve between ROS<string> and ROS<object>, see dotnet/sdk#41089 (comment). It may be a compiler bug, though.

Currently, the better conversion rules for collection expressions treat this case as ambiguous.

Perhaps there should be an additional rule to prefer System.ReadOnlySpan<E₁> over System.ReadOnlySpan<E₂> if an implicit conversion exists from E₁ to E₂.

There's a case where a collection expression can't resolve between ROS<string> and ROS<object>, see dotnet/sdk#41089 (comment). It may be a compiler bug, though.

Currently, the better conversion rules for collection expressions treat this case as ambiguous.

Perhaps there should be an additional rule to prefer System.ReadOnlySpan<E₁> over System.ReadOnlySpan<E₂> if an implicit conversion exists from E₁ to E₂.

I thought that was part of the first-class span support. Is it not, @333fred?

Perhaps there should be an additional rule to prefer System.ReadOnlySpan<E₁> over System.ReadOnlySpan<E₂> if an implicit conversion exists from E₁ to E₂.

I thought that was part of the first-class span support. Is it not, @333fred?

Unfortunately, implicit conversions from first-class span support may not be sufficient for a collection expression argument since implicit conversions are only considered in better conversion when the types are not span types.

• E is a collection expression and one of the following holds:
  • ...
  • T₁ is not a span_type, and T₂ is not a span_type, and an implicit conversion exists from T₁ to T₂

Currently, the better conversion rules for collection expressions treat this case as ambiguous.

This is tracked by dotnet/roslyn#73857.

Note for breaking change doc: If this ship as is, it should be pointed out that string.Trim*(params ROS<char>) will hide extension methods which usually match the whole sequence while the one added here matches any of the characters.

See #102822 (comment).