Proposal: Using non compile-time constants as optional parameter values

[DamienFlury]

For example:

void Foo(Random r = null) {
    r = r ?? new Random();
}

void Bar(Person person = null) {
    person = person ?? GetPerson("");
}

What if we could write:

void Foo(Random r = new Random()) {
}

void Bar(Person person = GetPerson("")) {
}

and the rest would be generated.

[DavidArno]

The problem I see with this idea is one of discoverability. If I have a method:

void UpdateDateOfBirth(DateTime newDateOfBirth, Person person = null)
{
    ...

Intellisense will show me that Person person = null as it's part of the method signature. Obviously, the method signature offers no clues as to what it does when given a null, so I'd have to go and look at the code.

What you are proposing is to have the compiler lower:

 void UpdateDateOfBirth(DateTime newDateOfBirth, Person person = new Person(""))
{
    ...

to:

 void UpdateDateOfBirth(DateTime newDateOfBirth, Person person = null)
{
    person = person ?? new Person("");
    ...

So the signature hasn't changed. As a consumer of your API, I'm gaining no benefit from this feature. I still have to examine the method body to understand what happens in the case of null. All it does is save you, the author, a few keystrokes when writing it. That doesn't offer a compelling case for prioritising this change over the hundreds of other requests here, in my view.

[DamienFlury]

Fair point, but in C# 8.0 nullable refence types probably will be implemented, so the current syntax wouldn't really work anymore if I'm correct:

void UpdateDateOfBirth(DateTime newDateOfBirth, Person person = null) // Warning: Person can't be null
{
    person = person ?? new Person("");
    ...

So the solution would be following (by declaring the parameter as nullable):

void UpdateDateOfBirth(DateTime newDateOfBirth, Person? person = null)
{
    person = person ?? new Person("");
    ...

So every method and constructor will still have all optional parameters as necessarily nullable...

[bondsbw]

Related: dotnet/roslyn#5474

I would prefer the CLR provide this capability without a need for lowering, but I seriously doubt this meets the standard for breaking forward compatibility.

[bondsbw]

@DavidArno

So the signature hasn't changed. As a consumer of your API, I'm gaining no benefit from this feature.

Perhaps an indicator attribute can be inserted so that future compilers (including other languages) can pick up on it.

[tannergooding]

Perhaps an indicator attribute can be inserted so that future compilers (including other languages) can pick up on it.

Wouldn't you know that the compiler already has such an attribute, but that it only works for System.Decimal 😄

public static void Main(String[] args) {
    Test();
}
    
static void Test(decimal d = 1.0m)
{
    Console.WriteLine(d);
}

gets emitted as:

using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;

public static void Main(String[] args) {
    var d = new decimal(1, 0, 0, 0, 10);
    Test(d);
}

static void Test([Optional, DecimalConstant(1, 0, 0, 0, 10)] decimal d)
{
    Console.WriteLine(d);
}

[tannergooding]

The framework also declares an abstract attribute, CustomConstantAttribute, which was originally meant for a similar purpose (user/compiler inherits from the class and implements the required logic to encode the constant info)

[HaloFour]

@tannergooding

Wouldn't you know that the compiler already has such an attribute, but that it only works for System.Decimal 😄

And VB.NET adds another for System.DateTime.

I'm not sure how practical it would be to make this general purpose, though. And the scenarios listed in the original post seem to indicate invoking some code vs. some kind of serializable value.

[HaloFour]

I vote that above comment be deleted for being off-topic, non-constructive and combative.

[terrajobst]

@HaloFour

I vote that above comment be deleted for being off-topic, non-constructive and combative.

We no longer delete comments but mark them appropriately. This allows us and the community to keep a record of problematic content.

[HaloFour]

@terrajobst

We no longer delete comments but mark them appropriately. This allows us and the community to keep a record of problematic content.

Good idea, otherwise it would look like I was trying to report myself. 😄

[AustinBryan]

Fair point, but in C# 8.0 nullable refence types probably will be implemented, so the current syntax wouldn't really work anymore if I'm correct:

You're not. All it is is a warning, nothing more. The code will still work fine.
Also, it's an opt-in feature, so it's even less harmful.

[Kryptos-FR]

Slightly different proposal, but often we have method overloads like (especially constructors):

class MyClass
{
    public MyClass()
        : this(int.MaxValue)
    {
    }

    public MyClass(int integer)
        : this(integer, TimeSpan.Zero)
    {
    }

    public MyClass(int integer, TimeSpan time)
        : this(time, integer, DateTime.Now)
    {
    }

    public MyClass(TimeSpan time)
        : this(time, int.MaxValue, DateTime.Now)
    {
    }

    public MyClass(TimeSpan time, int integer, DateTime date)
    {
    }
}

The idea would be to allow the developer to just write:

class MyClass
{
    public MyClass(TimeSpan time = TimeSpan.Zero, DateTime date = DateTime.Now, int integer = int.MaxValue)
    {
    }
}

with the constraint that non-compile-time constants must appear before compile-time constants.
Then the compiler would generate the combination:

class MyClass
{
    [Generated] // or some other attributes to help the analyser identify the candidates
    public MyClass(TimeSpan time, int integer = int.MaxValue)
        : this (time, DateTime.Now, integer)
    {
    }
    
    [Generated]
    public MyClass(DateTime date, int integer = int.MaxValue)
        : this (TimeSpan.Zero, date, integer)
    {
    }
    
    [Generated]
    public MyClass(TimeSpan time, DateTime date, int integer = int.MaxValue)
    {
    }
}

Of course the main inconvenient is the explosion of generated code. But I could see great benefit, since those "magic values" can now be more easily documented. And while they won't be visible in metadata (maybe as verbatim string representing the code??) a smart code analyser can still display them in an IDE.