Add overloads for validation problem results that accept IReadOnlyDictionary<string, string[]>

[DamianEdwards]

Sometimes all you have is a IReadOnlyDictionary and you don't want to have to downcast it or wrap it to pass it to the helper methods.

namespace Microsoft.AspNetCore.Http;

public static class Results
{
+    public static IResult ValidationProblem(IReadOnlyDictionary<string, string[]> errors,
+        string? detail = null,
+        string? instance = null,
+        int? statusCode = null,
+        string? title = null,
+        string? type = null,
+        IReadOnlyDictionary<string, object?>? extensions = null);

+    public static IResult Problem(
+        string? detail = null,
+        string? instance = null,
+        int? statusCode = null,
+        string? title = null,
+        string? type = null,
+        IReadOnlyDictionary<string, object?>? extensions = null);
}

public static class TypedResults
{
+    public static ValidationProblem ValidationProblem(IReadOnlyDictionary<string, string[]> errors,
+        string? detail = null,
+        string? instance = null,
+        string? title = null,
+        string? type = null,
+        IReadOnlyDictionary<string, object?>? extensions = null);

+    public static ProblemHttpResult Problem(
+        string? detail = null,
+        string? instance = null,
+        string? title = null,
+        string? type = null,
+        IReadOnlyDictionary<string, object?>? extensions = null);
}

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[captainsafia]

Triage: Marking this as ready for API review. Once it is approved for API review, this would be a good candidate for help wanted.

[halter73]

API Review Notes:

• Is this a breaking change? Yes. It's ambiguous which overload to pick if you pass in Dictionary<string, string[]>.
• Can we make it IEnumerable<KeyValuePair<string, string[]>> instead? Yes.
• Do we want to change both the errors and extensions parameters? Might as well. It will accept more arguments, and we're not modifying either dictionary.

API Approved!

namespace Microsoft.AspNetCore.Http;

public static class Results
{
+    public static IResult ValidationProblem(IEnumerable<KeyValuePair<string, string[]>> errors,
+        string? detail = null,
+        string? instance = null,
+        int? statusCode = null,
+        string? title = null,
+        string? type = null,
+        IEnumerable<KeyValuePair<string, object?>>? extensions = null);

+    public static IResult Problem(
+        string? detail = null,
+        string? instance = null,
+        int? statusCode = null,
+        string? title = null,
+        string? type = null,
+        IEnumerable<KeyValuePair<string, object?>>? extensions = null);
}

public static class TypedResults
{
+    public static ValidationProblem ValidationProblem(IEnumerable<KeyValuePair<string, string[]>> errors,
+        string? detail = null,
+        string? instance = null,
+        string? title = null,
+        string? type = null,
+        IEnumerable<KeyValuePair<string, object?>>? extensions = null);

+    public static ProblemHttpResult Problem(
+        string? detail = null,
+        string? instance = null,
+        string? title = null,
+        string? type = null,
+        IEnumerable<KeyValuePair<string, object?>>? extensions = null);
}

[joegoldman2]

I'm trying to implement this proposal but I have some questions:

• For all new overloads I'm getting the following warning: RS0026 Symbol 'ValidationProblem' violates the backcompat requirement: 'Do not add multiple overloads with optional parameters'. See 'https://github.com/dotnet/roslyn/blob/main/docs/Adding%20Optional%20Parameters%20in%20Public%20API.md'. Is it ok?
• I think the parameter int? statusCode = null is missing for the new Problem overload in TypedResults. It exists for the existing overload that accepts a IDictionary<string, object?>?.
  

  aspnetcore/src/Http/Http.Results/src/TypedResults.cs

  Lines 761 to 767 in c7aae8f

  	public static ProblemHttpResult Problem(
  	string? detail = null,
  	string? instance = null,
  	int? statusCode = null,
  	string? title = null,
  	string? type = null,
  	IDictionary<string, object?>? extensions = null)

• I think a new construtor overload that accepts a IEnumerable<KeyValuePair<string, string[]>> for HttpValidationProblemDetails is welcome in addition to the existing one which accepts a IDictionary<string, string[]>. This will make it easier to create a new instance from a IEnumerable<KeyValuePair<string, string[]>> and will also ensure a degree of consistency.
  

  aspnetcore/src/Http/Http.Abstractions/src/ProblemDetails/HttpValidationProblemDetails.cs

  Line 26 in c7aae8f

  public HttpValidationProblemDetails(IDictionary<string, string[]> errors)