Non-allocating Use middleware extension method

[BrennanConroy]

Background and Motivation

While profiling an app I noticed the two largest allocations were coming from the Use extension method. A Func<Task> and a lambda capture, equivalent to ~94 bytes per request.

The proposed API will remove both per-request allocations.

Proposed API

namespace Microsoft.AspNetCore.Builder
{
    public static class UseExtensions
    {
        public static IApplicationBuilder Use(this IApplicationBuilder app, Func<HttpContext, Func<Task>, Task> middleware)
+       public static IApplicationBuilder Use(this IApplicationBuilder app, Func<HttpContext, RequestDelegate, Task> middleware)
    }

Usage Examples

Before:

app.Use(async (context, next) =>
{
    await next();
});

New:

app.Use(async (context, next) =>
{
    await next(context);
});

Alternative Designs

No.

Risks

More overloads isn't always great as it can be detrimental to the developer experience. Fortunately the beginning of both the new and old overloads is the same and the only difference will be when invoking the next method.

It would be nice if we could somehow promote using the new overload over the old one to let developers know they can avoid the implicit allocations.

Additional Information

Possible implementation:

public static IApplicationBuilder Use(this IApplicationBuilder app, Func<HttpContext, RequestDelegate, Task> middleware)
{
    return app.Use(next =>
    {
        Func<HttpContext, Task> n = (c) => next(c);
        return context =>
        {
            return middleware(context, n);
        };
    });
}

[davidfowl]

cc @Tratcher

[Tratcher]

Before:

app.Use(async (context, next) =>
{
    await next();
});

New:

app.Use(async (context, next) =>
{
    await next(context);
});

Aren't those signatures ambiguous? How can the compiler tell if next is Func<Task> or Func<HttpContext, Task>?

[BrennanConroy]

Looks like the compiler can disambiguate based on return value. I.e. when you type await next() vs. await next(context) it can figure out which one to use.

[Tratcher]

Which return value does intellisence recommend first?

[BrennanConroy]

The first one, and unfortunately it doesn't show multiple options when typing next. It does show the new one before the old one when typing app.Use.

[davidfowl]

That can be fixed. Lets not gate APIs on intellisense features that we can influence 😄

[Tratcher]

Do we want an analyzer to recommend the right overload? We don't want to obsolete the old one, that's used everywhere.

[BrennanConroy]

Is there a [Recommend("use other")] sort of thing that will just give a message and green squiggly in VS?

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. 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.