struct as const

[bryancostanich]

Hey all (FYI rewrote this based on new ideas)!

Use Case

I have the following use case, I'd like to be able to use structs as compile time constants in method arguments like the following:

// built-in type:
public void StartUpdating(TimeSpan updateInterval = TimeSpan.FromMilliseconds(5000))

// AND with my own types:

public Something(Voltage voltageReference = new Voltage(3.3)) {...}

// OR something like:
const Voltage voltage = 3.3;
public Something(Voltage voltageReference = voltage) {...}

// OR
public Something(Voltage voltageReference = 3.3) {...}

Discussion

This has gnawed at me for a long time, but it has recently been causing API design headaches in Meadow. I naively thought that the challenge was that you can't declare a struct as const. But you can declare primitives, e.g.:

Allowed:

const int foo = 8;

Not allowed:

public struct Temperature
{
    private readonly double Value;
    public Temperature(double value) { this.Value = value; }
}
...
const Temperature temp = new Temperature(9);

Naive Approach

I understand that this happens at compile time and the compiler is supposed to compile, not execute code, but maybe we could add some const initializer syntax or something? so we could do something like:

public struct Temperature
{
   private readonly double Value;
   public const Temperature(double value) => this.Value;
}
const Temperature temp = 9;

alternatively, we could add an implicit operator, and have the compiler make sure that it's just a value set:

public static implicit operator Temperature(double value) => new Temperature(value);

In the end, the compiler is also serializing primitive types into IL, so why can't we serialize our value into this? as long as it didn't actually do any code execution, just value setting, then this would be possible, no?

Other (Better?) Approach

However, as pointed out by @CyrusNajmabadi, there may be another approach here that would work, which is to update the runtime and complier to reference static readonly fields in those locations.

I don't know the internals of the compiler/runtime well, I just know how I'd like to be able to code these APIs, so I'm open to approaches.

Thanks for reading.

[HaloFour]

As of now this is largely a runtime constraint. A literal field is only permitted to be one of a small subset of types that are understood by the runtime.

The C# compiler does workaround this limitation in some cases, such as decimal constants, but it does so by using a readonly field rather than a constant. Given the use case above you could do the same, there really isn't the need to use a constant there.

[CyrusNajmabadi]

Any solution that would enable that would require changes and work. As such, it would have to be weighed against alternative approaches (like making it so you could reference static readonly fields in those locations).

[bryancostanich]

a static readonly field wouldn't be bad either.

in any case, isn't that exactly why this repo exists? to start those conversations so the team can prioritize and do the work?

[HaloFour]

There are a few proposals to expand on the types allowed in "constant" expressions: #688

IMO any such change should include runtime support otherwise these "pseudo-constants" could never be supported in attributes. Constants and optional parameters can be faked by each compiler via custom attributes, although there is no general purpose version of such a beast. C# does this with decimal and VB.NET does this with decimal and DateTime.

[CyrusNajmabadi]

in any case, isn't that exactly why this repo exists? to start those conversations

No one was saying we shouldn't be having a conversation on this. This thread is the sort of conversation that ideas like this spark :-)

[bryancostanich]

:) thanks for the clarification. Appreciate the work being done here.