C# 9: why is the compiler unable to infer the type when using target-typed new with chained methods?

[IanKemp]

Consider the following extension method:

public static class ExtensionMethod
{
        public static THttpContext WithAuthorizationHeader<THttpContext>(this THttpContext httpContext, string value)
            where THttpContext : HttpContext
        {
            httpContext.Request.Headers.Add(HeaderNames.Authorization, value);

            return httpContext;
        }
}

The following code happily compiles, as expected:

var context = new DefaultHttpContext().WithAuthorizationHeader($"Bearer {token}");

But this code does not, even though I would expect it to:

DefaultHttpContext context = new().WithAuthorizationHeader($"Bearer {token}"); // CS8754 "There is no target type for 'new()'"

It appears the compiler is attempting to parse the entirety of the expression and infer the type from that, whereas to my mind it should be parsing and resolving DefaultHttpContext context = new() first, then evaluating the chained method call.

I have checked https://docs.microsoft.com/dotnet/csharp/language-reference/proposals/csharp-9.0/target-typed-new but can't see anything that would imply this shouldn't work.

[svick]

to my mind it should be parsing and resolving DefaultHttpContext context = new() first, then evaluating the chained method call

Why would it do that? The compiler hasn't performed overload resolution yet, so it doesn't know that the type of the new() subexpression is going to be the same as the type of the whole expression. And without that, there is no connection between new() and DefaultHttpContext.

[tannergooding]

i believe the customer request though is to rewrite the above as:

Right. I was just trying to explain why the code doesn't make sense/work today.

That being said, I also don't like this and don't think this is intuitive, particularly given how expressions work in C# today. But that's my personal opinion here.

[CyrusNajmabadi]

how is this syntax: ... Any better than this?

One could be used in a field, the other could not.

[TahirAhmadov]

One could be used in a field, the other could not.

I knew somebody would bring it up! Well, first of all, code like this doesn't belong in a class initializer - it may legally, but it's highly unlikely to actually happen. Second, even in a field, as much as we all hate typing, Class _c = new Class().Configure().Build().Make(); is all of N-3 more letters to type, where N is the name of the class. Given that a) it's a rare form and b) it only saves a few keystrokes (or none at all with autocomplete), I think the cost is huge and benefit is almost non-existent.

[CyrusNajmabadi]

Well, first of all, code like this doesn't belong in a class initializer - it may legally, but it's highly unlikely to actually happen

I don't really have any confidence in that statement.

[TahirAhmadov]

I don't really have any confidence in that statement.

I do. :)

[DavidArno]

I have checked https://docs.microsoft.com/dotnet/csharp/language-reference/proposals/csharp-9.0/target-typed-new but can't see anything that would imply this shouldn't work.

In the miscellaneous section, it states it will not work:

"It is disallowed when ... in a member access (new().field) ..."