[Proposal]: Support optional and named arguments in Expression trees

[cston]

Summary

Support optional and named arguments in method calls in Expression trees

Motivation

Errors are reported for calls in Expression trees when the call is missing an argument for an optional parameter, or when arguments are named. This results in unnecessary code and differences for expressions within Expression trees.

The compiler restrictions should be removed if not needed.

For example, compiling the following with the .NET 10 preview SDK results in errors currently.

namespace System
{
    public static class MemoryExtensions
    {
        public static bool Contains<T>(this ReadOnlySpan<T> span, T value, IEqualityComparer<T>? comparer = null);
    }
}

Expression<Func<int?[], int, bool>> e;
        
e = (a, i) => a.Contains(i); // error CS0854: expression tree may not contain a call that uses optional arguments
e = (a, i) => a.Contains(i, comparer: null); // error CS0853: expression tree may not contain a named argument specification

Detailed design

Drawbacks

Alternatives

Unresolved questions

It's unclear why the restrictions were added originally. An initial investigation hasn't revealed an issue supporting these cases.

Design meetings

Based on a suggestion from @roji to support optional parameters.

[TahirAhmadov]

#4727

[jaredpar]

That is a much broader issue, this is meant to be a very targeted change.

[colejohnson66]

The restriction exists because optional parameters didn't exist when expression trees were created, and the team has steadfastly refused to expand their support (short of a hypothetical "Expressions2").

IMHO, optional parameters could be supported without breakage by lowering them the same way the compiler does: including the implicit parameter at the call site. The expression consumer would see nothing different than if the user manually wrote the comparer: null argument.

[cston]

IMHO, optional parameters could be supported without breakage by lowering them the same way the compiler does: including the implicit parameter at the call site.

Yes, that was our expectation from initial experiments, that it might be sufficient to remove the error reporting for named and optional arguments in Expression trees and use the existing lowering for those cases.

[jaredpar]

The restriction exists because optional parameters didn't exist when expression trees were created, and the team has steadfastly refused to expand their support (short of a hypothetical "Expressions2").

I went down the rabbit hole a few weeks ago on this topic. Basically, this is seemingly a trivial change to the compiler, remove error + add testing, so why didn't we do it? Yes it wasn't added to expression trees initially because the language didn't support it, but that was fixed in C# 4.0 so why didn't we extend expression trees then? I went through the old C# design notes, a few issues from the old database, chated with the devs on the C# LDM at the time, including Mads, and no one knows. The why is basically lost to history at this point.