Proposal: Compile Time Function Execution

[gafter]

@nikeee commented on Wed Mar 09 2016

Let's take this code:

class SomeClass
{
    public const string AConstString = "Foo";
    public const string AnotherConstString = AConstString + "Bar";
}

This works as expected, therefore, the value of AnotherConstString will be set to "FooBar" by the compiler. The IL does not contain anything like AConstString + "Bar". Instead, any use of the constant values above will be inlined to its constant value.

Now take a look at this code:

class SomeOtherClass
{
    public const string AConstString = "Foo";
    public static readonly string AnotherConstString = CreateAnotherString(AConstString);

    private static string CreateAnotherString(string prefix) => prefix + "Bar";
}

This already works as of today. The difference here is that AnotherConstString is clearly a constant value that can be determined at compile time. So what ends up in the IL is a reference to the static field AnotherConstString while CreateAnotherString will be invoked by the static constructor during runtime.

The code:

Console.WriteLine(SomeClass.AnotherConstString);
Console.WriteLine(SomeOtherClass.AnotherConstString);

Compiles to this IL (with optimizations enabled):

ldstr     "FooBar"
call      void [mscorlib]System.Console::WriteLine(string)
ldsfld    string ctfe.SomeOtherClass::AnotherConstString
call      void [mscorlib]System.Console::WriteLine(string)

So, if the compiler knew that CreateAnotherString has no side effects and its return value is entirely based on its parameters and the parameters are compile time constants, the compiler itself could evaluate the function.
The function is required to be a pure function. There already is a proposal for pure functions, since they may have additional benefits.

This could also affect cases like these:

public static void Baz(int foo)
{
    if(foo < 0)
        throw new ArgumentException($"{nameof(foo)} must be greater than or equal to zero.");
}

Currently, what ends up in the IL will be something like this (translated back to C#):

string.Format("{0} must be greater than or equal to zero.", "foo")

If string.Format is a pure function, all parameters are compile time constants, so the compiler could actually invoke string.Format and emit the result instead:

"foo must be greater than or equal to zero."

Of course, if a function is pure, it can remain in the compiled assembly, in case someone invokes it with non-constant parameters.

const string constFoo = "Foo";
string varFoo = "Foo";
Console.WriteLine(SomeOtherClass.CreateAnotherString(constFoo)); // becomes "FooBar"
Console.WriteLine(SomeOtherClass.CreateAnotherString(varFoo)); // remains SomeOtherClass.CreateAnotherString(varFoo)

Other thoughts:

• Evaluating constructors at compile time? (Could it be used for constant immutable structs?)
• If a user-defined struct is constant and its overloaded operators can be evaluated by the compiler, something like const Vector2 upLeft = Vector2.Up + Vector2.Left would be a constant expression. This is actually the same thing as in the code of SomeClass above, just using Vector2 instead of string.
• Common functions of the framework may be marked as "pure" or "constexpr" (e. g. string.Format, Convert.*, string.Join) without losing compatibility.
• Regarding strings: "FooBar" is a compile time constant, so "FooBar".Length or "FooBar".get_Length() may return constant values. Imagine using it in a scenario like str.Remove(str.Length - "RemoveMe".Length), while the code remains maintainable because "RemoveMe".Length is more self-explanatory than just 8. If str is a constant and Remove is a pure function, the entire expression may be computed by the compiler.

This feature would be pretty similar to other languages supporting CTFE, like D or C++11 with constexpr.
Also, CTFE doesn't have to be implemented in the compiler that compiles to IL. It may be also implemented in the JIT or other AOT compilers.

---

@svick commented on Wed Mar 09 2016

In the case of static readonly field, what is the point of optimizing the IL? Under normal circumstances (JIT compilation), it will behave as a constant during JIT anyway (i.e. the CLR executes the field initializers and only then JIT compiles the method, knowing the field can't change).

In the case of interpolated strings, string.Format() is not a pure function (it depends on the current culture), so this also wouldn't help (see #9212).

The constant.Length optimization sounds like something the JIT compiler should be able to do (but as far as I can tell, doesn't currently do).

[Unknown6656]

Related to:

• dotnet/csharplang#1763: "[C#-X.0 Proposal] Determinism"

which references:

• dotnet/csharplang#504: "Enable Compile-Time Folding of Deterministic Outputs"
• dotnet/csharplang#776: "C# Pure Function Keyword to Mark No Side Effects Or External Dependencies"
• dotnet/csharplang#1028: "Compile time expressions"
• dotnet/csharplang#1413: "Compile-Time method inlining"
• dotnet/roslyn#9627: "Compile Time Function Execution"
• dotnet/roslyn#10506: "Static Expressions"
• dotnet/roslyn#11259: "Constant string interpolation"
• dotnet/roslyn#12238: "Compile time expressions"
• dotnet/roslyn#14665: "Constant expression - Power operator?"
• dotnet/roslyn#15079: "How would you imagine constexpr in C#?"
• dotnet/coreclr#3633: "Optimizing constant_string.Length"

[AraHaan]

This would be great, however what if the strings to place into the format strings is only known at runtime based on user input data? I feel with the user input data which would only be known at runtime would eliminate the benefits of this only in those places.

The same can also be true with application settings reading that then control what a value will be like for example the program loads an settings.json file which in turn tells it which icon to use at runtime when loading the program based on an icon index number hard coded into said program (used by some gui programs too).

[nikeee]

There is #2951 (defined in this proposal) to address constants in string interpolations.

[nikeee]

Reading the latest blog post about Performance Improvements in .NET 6, this feature seems largly obsolete, as it is mostly covered by the constant folding approach.

[Xyncgas]

What if I want to distribute my software with DRM key that I want it to be computed when compiling. What if I want the 99999th fibonaci number converted to a string when compiling

[HaloFour]

https://docs.microsoft.com/en-us/visualstudio/modeling/code-generation-and-t4-text-templates?view=vs-2022

[Xyncgas]

We still need this

[En3Tho]

Funny but as a workaround you can use SourceGenerator for this. From your example above, you basically make a partial class DRM and compute the key in a source generator.

[TahirAhmadov]

I still think this is very useful, even despite the .NET 6 improvements. Clearly, others think so, too - what with the UTF-8 string literals being added to the language.

[Alluseri]

This is still needed

[tuscen]

Having compile time execution would be really great. Especially when having to deal with attributes.

[CyrusNajmabadi]

@Xyncgas please open issues with tooling over at dotnet/roslyn

[Kaexzr]

This would be great.

[asafalgawi]

Is this being tracked ?

[TonyValenti]

I would love to see something like this. It would be great if the compiler took a multi-pass approach.

1. Compile the DLL and tag special locations.
2. Run the compiled methods, "serialize" the result, and then replace the call sites with the serialized values.

I use "serialize" lightly because the serialization should return C# code that can generate the object.

[HaloFour]

Horrifically, sounds like something a source generator and interceptor could do.