Add Extensions to Http.TypedResults

[dnperfors]

Background and Motivation

TypedResults has a very similar api as Results, but it lacks an Extensions property.

This property would be useful for consistency, all endpoints can use TypedResults even when using customized results via an extension. Besides that there seem to be plans the recommend and add a codefixer for using TypedResults where possible. (#45217)

Proposed API

namespace Microsoft.AspNetCore.Http;

public static class TypedResults
{
+    public static IResultExtensions Extensions { get; } = new ResultExtensions();
}

Usage Examples

app.MapGet("/",  () => TypedResults.Extensions.CustomResult());

Alternative Designs

Alternatively a new specific interface could be used instead:

namespace Microsoft.AspNetCore.Http;

+ public interface ITypedResultExtensions { }

public static class TypedResults
{
+    public static ITypedResultExtensions Extensions { get; } = new ResultExtensions();
}

Risks

When going for the proposed solution, existing extensions automatically become available, even if they are not 'Typed'.

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

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 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.

[halter73]

API Review Notes:

• Why did we add Results.Extensions in the first place? Mostly discoverability of custom IResult types.
• The workaround is just continue using Results.Extensions and return strong types from custom IResult types.
• Is it confusing to include an Extensions in both places? It might less confusing because it's the only member of Results that's not in TypedResults.
• Do we like the alternative design? It provides more flexibility. You could have one IResult-returning method better for multiple return points in a lambda, and one that's type. It could be confusing if extensions that showed up on one didn't on the other though. And it's a lot more ceremony for custom IResult authors.

API Approved as proposed!

namespace Microsoft.AspNetCore.Http;

public static class TypedResults
{
+    public static IResultExtensions Extensions { get; } = new ResultExtensions();
}

[davidfowl]

We might be getting extension everything in C# 12, so hopefully, this will be obsolete in the future.

cc @jaredpar @MadsTorgersen

[dnperfors]

I can provide a PR with the implementation.