Introduction

That error usually appears when an optional parameter is assigned a value the compiler cannot embed at compile time. In languages such as C#, and in similar default-argument systems elsewhere, the default value must be something the compiler can write directly into the call site rather than something that has to be computed at runtime.

Why the Rule Exists

Optional arguments are often substituted at the caller, not looked up dynamically every time the method runs. That means the compiler needs a value it can know immediately when it compiles the call.

Simple examples of compile-time constants are:

• numeric literals such as 42
• string literals such as "hello"
• 'true, false, and null'
• enum values

Values that require runtime evaluation are not valid defaults.

A Typical Invalid Example

In C#, this causes the error:

1using System;
2
3class Example
4{
5    static void Log(DateTime timestamp = DateTime.Now)
6    {
7        Console.WriteLine(timestamp);
8    }
9}

DateTime.Now is evaluated at runtime, so it is not a compile-time constant.

A similar problem appears with new expressions, method calls, and most non-const variables.

Valid Default Arguments

These are fine:

1class Example
2{
3    static void Print(int count = 10, string label = "default", bool enabled = true)
4    {
5    }
6}

The compiler can embed these values directly.

In modern C#, default(SomeType) or default can also be valid in some cases where the language permits it, because the compiler can resolve it statically.

Use null and Fill It In Inside the Method

A common workaround is to use null as the optional parameter value and compute the real value inside the method.

1using System;
2
3class Example
4{
5    static void Log(DateTime? timestamp = null)
6    {
7        var actualTimestamp = timestamp ?? DateTime.Now;
8        Console.WriteLine(actualTimestamp);
9    }
10}

This is usually the cleanest solution when the logical default depends on the current time, environment, or some other runtime state.

Overloading Is Another Good Option

Method overloading is often clearer than complex optional-parameter logic.

1using System;
2
3class Example
4{
5    static void Log()
6    {
7        Log(DateTime.Now);
8    }
9
10    static void Log(DateTime timestamp)
11    {
12        Console.WriteLine(timestamp);
13    }
14}

This avoids optional-parameter constraints entirely and makes the runtime default behavior explicit.

const Versus readonly

A frequent source of confusion is the difference between const and readonly in C#.

1class Example
2{
3    private const int DefaultPort = 8080;
4    private static readonly DateTime StartupTime = DateTime.Now;
5
6    static void Connect(int port = DefaultPort) { }
7    // static void Run(DateTime when = StartupTime) { } // invalid
8}

const values are compile-time constants. readonly values are assigned at runtime, so they cannot be used as optional parameter defaults.

The Same Idea in Other Languages

Although the exact error text varies, the same principle appears in other statically compiled languages that support default arguments. The compiler needs a stable value that does not depend on runtime execution.

So even if the title sounds language-generic, the underlying idea is consistent:

• default argument values are usually restricted because the compiler needs to substitute them safely and predictably

When the Runtime Value Is the Real Requirement

If the desired default genuinely depends on runtime state, then it is not really a compile-time default. That is a clue that the API should use one of these patterns instead:

• nullable optional argument plus in-method fallback
• overload with no argument
• configuration object
• builder or options pattern

Choosing one of those usually produces a better API than trying to force a runtime expression into a compile-time slot.

Common Pitfalls

• Using DateTime.Now, Guid.NewGuid(), or method calls as default parameter values.
• Assuming readonly fields count as compile-time constants.
• Forgetting that optional-argument values are generally baked into call sites.
• Treating a runtime-dependent value as if it were just a slightly more complicated literal.
• Forcing optional parameters where a method overload would express the intent more clearly.

Summary

• Optional parameter defaults usually must be compile-time constants.
• Literals, null, enum values, and true compile-time constants are valid.
• Runtime expressions such as DateTime.Now are not valid defaults.
• Use null plus in-method fallback or overloads when the real default depends on runtime state.
• The rule exists because the compiler needs a stable value it can substitute predictably.