Reapply keyword params

[jozkee]

Closes #101261.
Closes #77873.

Continuation of #101308.

[dotnet-issue-labeler]

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.

[stephentoub]

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

[stephentoub]

/azp run

[azure-pipelines]

You have several pipelines (over 10) configured to build pull requests in this repository. Specify which pipelines you would like to run by using /azp run [pipelines] command. You can specify multiple pipelines using a comma separated list.

[dotnet-policy-service]

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.

[stephentoub]

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

[jozkee]

source breaking?

[stephentoub]

Can you elaborate?

[jozkee]

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?

[cston]

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₂.

[stephentoub]

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?

[cston]

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₂

[cston]

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

This is tracked by dotnet/roslyn#73857.

[jozkee]

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).