[Proposal]: Non-Compile Time Constant Default method parameter values

[digitalcreature]

Non-Compile Time Constant Default method parameter values

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

Right now, when declaring default values for method parameters, the expression must be a compile-time constant. Sometimes it would be nice to be able to declare a default value that is evaluated at call-time, such as instantiating a default object or struct.

// allowed
void Foo(Random rng = null) {
  // do something
}
// not allowed
void Bar(Random rng = new Random()) {
  // do something
}

Motivation

The current workaround for this is to use a method overload, or to check for a compile time default value such as null:

// check for null
void Foo(Random rng = null) {
  rng = rng ?? new Random();
 // do something
}

// overload
void Bar(Random rng) {
  // do something
}
void Bar() => Bar(new Random());

The former introduces a branch whose evaluation is known at compile time based on call site, but needs to be evaluated at every call. It also prevents passing the value null when it is desired as it will always be overwritten.
The latter is simple enough with one parameter, but it gets unwieldy with additional parameters, as well as 2^n overloads for a method with n parameters with non-comptime constant values. This is excessive boilerplate.

Detailed design

Implementation should be trivial with lowering. Simply generate the needed overloads when these such parameters are encountered.

[YairHalberstadt]

Implementation should be trivial with lowering. Simply generate the needed overloads when these such parameters are encountered.

Which overloads should be generated in the following case:

void M(List<int> a = new List<int>(), List<int> b = new List<int>()) {...}

[HaloFour]

@digitalcreature

Implementation should be trivial with lowering. Simply generate the needed overloads when these such parameters are encountered.

As @YairHalberstadt highlights overloads cannot be generated for methods with default parameter values due to the fact that they will create collisions where two such overloads will have the same signature. Even if that was not the case it doesn't take too many optional parameters before you result in an explosion of overload methods.

[YairHalberstadt]

A lowering method that could work would be this:

void M(List<int> a = new List<int>(), List<int> b = new List<int>()) {...}

Is lowered to:

void M([Optional, DefaultValueMethodCall("DefaultValue<>M<>List`1<>List`1<>0")] List<int> a, [Optional, DefaultValueMethodCall("DefaultValue<>M<>List`1<>List`1<>1")]] List<int> b) {...}

public DefaultValue<>M<>List`1<>List`1<>0 => new List<int>();
public DefaultValue<>M<>List`1<>List`1<>1 => new List<int>();

And then at the callsite generate:

M(DefaultValue<>M<>List`1<>List`1<>0, DefaultValue<>M<>List`1<>List`1<>1)

However as you can see this would be much more complicated to design and implement...

[HaloFour]

Scala has an interesting way of enabling expressions for default values for optional parameters. It emits another method on the type declaring the method which contains the expression. When you omit the optional parameter at the call site the compiler automatically emits an invocation of that method to obtain the default parameter value which it then embeds into the call. So you write something like this:

class Program
{
    void Foo(DateTime date = DateTime.Now) => Console.WriteLine(date);

    void Bar()
    {
        Foo();
    }
}

and the compiler emits (something like) this:

class Program
{
    void Foo([Opt("Foo_date")] DateTime date) => Console.WriteLine(date);

    DateTime Foo_date => DateTime.Now;

    void Bar()
    {
        Foo(Foo_date);
    }
}

While it does enable these expressions it is also brittle in a couple of ways. It exposes the negotiation of the default parameter to the public surface of the type, and changes to the default values can break existing consumers. That's currently not a problem as the default value is only negotiated by the compiler and embedded directly in the call.

[YairHalberstadt]

Also duplicate of #1702

[digitalcreature]

Implementation should be trivial with lowering. Simply generate the needed overloads when these such parameters are encountered.

Which overloads should be generated in the following case:

void M(List<int> a = new List<int>(), List<int> b = new List<int>()) {...}

void M(List<int> a) => M(a, new List<int>());
voic M() => M(new List<int>(), new List<int>());

Overload generation follows the current way method calls with default parameters are determined.
For example:

void Foo(int a = 0, int b = 1) {
  Console.WriteLine($"{a}, {b}");
}

Foo(4, 5); // 4, 5
Foo(4);    // 4, 1
Foo();      // 0, 1

Because we know that calling with one argument would always assign that value to the first of the two parameters with the same type, we'd generate only the overloads that follow this pattern.

@YairHalberstadt @HaloFour As you can see, no collisions.

[HaloFour]

@digitalcreature

That doesn't take into account named parameters and would make the following impossible:

Foo(b: 4);  // 0, 4

The compiler can't just skip those overloads.

[digitalcreature]

@HaloFour Good point. I suppose we could do some name mangling and do lowering at the callsite as well.... not as elegant, but possible.
So for the same method foo, wed generate:

void Foo(int a) => Foo(a, 1);
void Foo_named0(int b) => Foo(0, b);
void Foo() => Foo(0, 1);

And use the Foo_named0 at a callsite that passes a value to b by name.

[YairHalberstadt]

@digitalcreature there are plenty of methods with 20 optional parameters. That would require generating over a million methods!

[digitalcreature]

@YairHalberstadt we would only generate overloads for non-constant default parameters; I can't imagine many use cases that would require that many nonconst optionals. Also having 20 parameters in the first place seems like bad practice, I doubt there can really be that many of them.

[HaloFour]

we would only generate overloads for non-constant default parameters;

That could make changing the default value a breaking change. There are a lot of cases where it's not obvious whether changing the expression would lead to such a break, such as default(CancellationToken) and CancellationToken.None.

Also having 20 parameters in the first place seems like bad practice

The reason support for optional parameters was added to C# at all was to improve the story with Office interop, where it's normal for methods to have a large number of optional parameters. From what I understand the teams originally tried to solve the problem with tooling that would generate overloads but that caused all of the problems listed above and was determined to be an untenable solution. Adding optional parameters (and a few other language features) was a compromise.

[SB16Tech]

why not just have the compiler treat optional parameters similar to nullable ones and just assign the expression to it right before executing the beginning of the method?

void Example(TestA a = new TestA())
{
   //do method
}

would basically be compiled down to..

void Example(TestA? a = null)
{
   if (a == null ) a = new TestA();
   //do method
}

of course we would still want to obey real nullables, so assigning something like null or a nullable wouldn't be possible to non nullables

void Example(TestA a = null) //warning or error whatever 
{
   //do method
}

[SB16Tech]

HaloFour means, what if you WANT to pass in null? This system would prevent you from being able to do so.

like I said it would probably be treated as Nullable<Nullable< T >> if it can be and the first nullable would be basically compiled out leaving you with Nullable< T >
basically the first nullable would only be for the compiler to use we would never actually see or use it

The first Nullable could even be a struct like OptionalParameter< T > or something but that would expose a new struct which isn't really a good thing for something that is a compiler feature.
Anyways I don't really care how it's done, i'm just saying it's possiable

[HaloFour]

It wouldn't be possible without silently changing the signature of the method.

[SB16Tech]

It wouldn't be possible without silently changing the signature of the method.

That's why it would be a compiler feature.
The part of it copying the default parameter expression already requires it to perform compiler magic.

And it doesn't need to be nullable either, the compiler can just check if the parameter is supplied if not pass in that expression.
So for example if a method had a function signature like this...

void M(List<int> a = new List<int>(), List<int> b = new List<int>()) {...}

It would literally be compiled to...

void M(List<int> a = new List<int>(), List<int> b = new List<int>())

We literally treat it the same as..

void R(int a=0, int b=0);

and...

new SomeType(...)

Should be treated as a compile time constant since we already know it will return a instance of that type unless a exception occurs in which case it's either handled or the program aborts.

And it would work with parameterized constructors too since we already know it's at least a instance of that type.

Also the class or struct members are also irrelevant due to knowing the type they will be by the time the object is constructed.

[HaloFour]

That's why it would be a compiler feature.

I don't know what that means. You're suggesting that the caller pass in a value outside of the possible values of the parameter type. That makes it affect the signature of the method. You can no longer have the method accept int because it's impossible to pass null or unassigned or whatever, and that breaks the meaning of the written code. The "compiler magic" applied for default parameters today does not do this. Yes, the compiler does interpret the default parameter metadata and emit a call that includes that default value, but the signature of the method is completely unaffected.

If you're suggesting that the compiler embeds the expression in the caller, as it does today, then that does not involve affecting the signature and would be compatible with how default parameters work today. The problem is how you encode that default value as metadata that can be interpreted by the compiler in order for it to emit the proper expression. You can't embed an instance of SomeType, you have to embed something that describes how to invoke the constructor, and how to pass any necessary parameters. That gets much more involved for arbitrary expressions. And this convention would need to be something understood by more than the C# compiler.

[En3Tho]

I'm kinda failing to see what is the difference from compiler's point of view in examples between

void M(List<int> a = new List<int>(), List<int> b = new List<int>())

and

void M(List<int> a = null, List<int> b = null)

One of things is encoding via Optional/DefaultParameterValue vs some new encoding but that was already proposed in this thread via generation of a special method and baking it's name into an attribute.

But what is this fundamental difference?

[aradalvand]

There is no reason for this not to be supported at this point.

[CyrusNajmabadi]

@aradalvand see the conversation above. There are many design concerns that no one has provided any solutions for.

[tannergooding]

I'd also say that its not that useful in practice.

The JIT is very good at inlining and optimizing, even giving profitability boosts for calls with known constants (meaning Random random = null is more likely to be better optimized). So in practice, the branch for random ??= new Random() is likely not going to be there, unless the method was already large enough that inlining was impossible (in which case the branch won't be meaningful and will likely even be well predicted).

If it is truly perf critical, then the best option is for an explicit separate overload (not optional parameters).

This is mostly a minor convenience factor and not even one that saves you that much compared to the alternatives. It can even be undesirable due to how it negatively impacts API surface evolution over time, percieved UX for the APIs, and the special considerations that must be taken for binary compat (hence why the Framework Design Guidelines generally recommend doing it sparingly and carefully).