Why do some languages have both immutable "variables" and constants?

Question

Some programming languages (Rust is one I can think of off the top of my head) provides mechanisms to have immutable variables but they also have constants. Isn't an immutable variable just a constant? What advantage is there in supporting both?

Answer 1

In many programming languages, a constant refers exclusively to compile-time constants. C, C++, and JavaScript do not appear to make this distinction and instead use the keyword for immutable bindings, but it appears in Rust, Nim, C#, Go, Kotlin, Lean...

So yes, a run-time constant is just an immutable variable. And no, a compile-time constant is not the same as an immutable variable. While distinctions between mutable and immutable variables are quite important for both compilers and programmers, a compile-time constant has a fixed value in memory, known to the compiler, and so many more optimizations may be done with it.

Terminology issues abound in computer science and I do not doubt that many other languages I've missed refer to immutable variables as constants, but it does appear broadly much more common for them to refer to values known at compile-time. See also: the idea of constexpr (C++), const exprs (Rust), comptime (Zig), static (Nim)... also, quite funny to see C++ pick up constexpr for compile-time evaluated expressions, in contrast to const's behavior in the language.

Answer 2

A constant is a variable whose value cannot change at all, whereas an immutable variable is a variable whose value cannot change for the lifetime of the variable, i.e. while the variable is in scope, but the value can be different between different lifetimes.

Consider the following Rust example:

const FOO: usize = 5;

fn bar(x: usize) -> usize {
    let y = x + 5;
    y * 2
}

fn main() {
    println!("{}", FOO);
    println!("{}", bar(6));
    println!("{}", bar(7));
}

In this example, FOO is a constant, since its value can never change at any point during program execution. On the other hand, y is an immutable local variable, whose value cannot change within a single activation of the function bar. But y can have different values at different times ─ in this program, it takes the values 11 and 12. Likewise, x is an immutable variable taking the values 6 and 7.

^{Note that the use of the word "lifetime" above does correspond with lifetimes in Rust's ownership model, but the same would apply in any other language.}

Answer 3

Why Have Different Syntax?

I think it's safe to say that, in general, languages make syntactic distinctions like this when

1. a compiler could not (reasonably) determine which option to use without the distinction, but no option is an acceptable default; or when
2. the language wants the programmer to positively opt into an option, because there are consequences.

In the case of immutable variables versus constants, I'd say it's a bit of both.

Immutable Variables and Constants

Immutable variables and constants are very similar, and some languages are happy to treat them as the same thing. I think, at least in the context of this question, we should differentiate them.

An immutable variable is simply a variable (a name referring to storage) that is immutable, by which we mean assigned at most once (or exactly once, depending on the language) at run time. This frees the compiler to make assumptions about the variable—for example, once the variable is assigned, the compiler can copy its value without worrying about synchronization.

A constant is one step further: it's a name referring to a static value, known at compile time. They don't necessarily refer to any storage—often the compiler just inlines their value into every expression that references them (depending on the language and compiler).

Different Syntax Because the Compiler Can't Decide

As I said, some languages are happy with one syntax for both immutable variables and constants. These languages may fall back to an immutable variable if the compiler can't determine that it could use a constant, or they may not have a concept of constants (as we've defined them) at all. Some languages, on the other hand, require separate syntax because it's not acceptable to default one way or the other.

One key difference between the two, in languages with pointers or references, is that immutable variables must refer to storage, and so have a defined address. On the other hand, constants need not refer to storage—depending on the language, constants may not have a defined address at all (as with C and C++ preprocessor constants), or their address may refer to a temporary copy and be different for each reference (as with Rust constants).

Also, since constants may be inlined, it may not be possible to recover their value at run time—e.g., for dynamic linking. There's not necessarily a variable to read, and if the language doesn't offer reflection the value may have been erased entirely during compilation.

Given these differences, it would never really be safe for the compiler to choose to use a constant for any public symbol. It would be disastrous if the compiler inconsistently chose to use a constant, because there would be observable differences in behavior and in ABI depending on the choice. But even if the compiler consistently chose to use a constant, it couldn't know if modules linking against this one would need to take references to the potential immutable variable, or read its value.

But it's also not acceptable for these languages to give up the ability to define constants—they're a very useful and common optimization. So, the language makes the programmer choose.

Different Syntax to Make the Programmer Positively Opt In

A language may also want a programmer to positively opt in to using a constant. Constants are generally more restrictive than immutable variables, since constants' values must be known at compile time. So the language makes the programmer intentionally choose one way or the other, even if the language could potentially make good automatic choices in some cases.

Imagine a language that has a single syntax to define immutable variables and constants, where the compiler uses a constant when it could determine the initializer's value at compile time, and creates an immutable variable otherwise. We might start out with a simple, obvious constant like

# Made up syntax...
const var FOO = 3

But this might evolve. It might get changed later to

const var FOO = 3 * 1000

Is this still a constant? It depends whether this language supports multiplication in constant expressions—many do, but if not then FOO just switched to an immutable variable. (And if multiplication is allowed, what about a function call?) If we're lucky, our change would lead to compilation errors or failed tests elsewhere in the module. But if not, there may not be any indication we changed something until we start receiving bug reports from downstream projects that link against ours.

Things would get especially tricky if the language also offered user-defined constant functions (such as C++ constexprs and Rust const fns), where a function could change from constant to non-constant and turn constants into immutable variables at a distance (or vice versa).

So instead, languages where the distinction matters tend to use separate syntax for declaring immutable variables and constants. Once the programmer has opted into one or the other, the compiler can preserve the programmer's stated intention—raising errors for misuse if necessary.

Answer 4

@apropos has covered most of this, but I just thought I'd pick up on a point about terminology and add more detail.

A "constant" is typically a field (an area of computer memory treated conceptually by the programmer as a single unit of storage) whose value is assigned in source code and stored statically in the compiled executable file, with the value specified in source code either as a literal, or perhaps as a simple expression of other constants.

Storage for a constant is allocated statically (a space is reserved in the executable itself), and the value of a constant is loaded from the executable into main memory at the same time that the whole program is loaded into main memory by the operating system. This means the value of the constant is already set before the program begins running, and the value does not change for the lifetime of the running program.

A "variable" is a field whose value is assigned (and reassigned) at run-time by the program. Unlike constants, variables can be computed at run-time from inputs that wouldn't have been available at compile-time. Unlike constants, the storage for variables can also be allocated and deallocated dynamically - that is, variables can be allocated in main memory, but have no equivalent space already reserved in the executable as constants do.

An "immutable variable" is a term for a variable that is assigned only once by the program, typically at the site of declaration. That is, fundamentally it is a variable (in the variable/constant distinction described above), except only one initial assignment is allowed. This single-assignment is enforced by the compiler.

"Immutable" may have been a misnomer originally in the sense that there is a run-time mutation, although in usage the term "immutable" has come to mean "mutable once only".

To confound things further, many languages allow variables to be initialised from literals stated in the source code, much like constants are initialised. In this case, what happens in practice is that an anonymous constant is created by the compiler to store the literal value in the executable, and then at run time the value of the anonymous constant is copied into the variable.

The essential difference between constants and immutable variables, is that constants have their values built at compile-time, whereas immutable variables have their values built at run time.

Constants are immutable across all executions of a particular compiled program, whereas immutable variables are only necessarily immutable for the lifetime of a single run of the program. You can start another run of the same program, and the value of the constant will be the same for both, but the value of the immutable variable may well differ.

Final thought: perhaps the word "irremutable" would have been a better term, capturing the idea that it is the ability to re-mutate which is excluded, not the ability to mutate at all.

Answer 5

If it is a variable, regardless if immutable or not, you can get the address of it when needed (a language must support a concept of the pointer to immutable object for this to work safely). A compile time constant has no address.

An address of the immutable object can be used:

• For easy check if it is the same object.
• For sharing the immutable object.
• When using immutable pointers to "user objects" like tree data nodes.
• When passing variables of various sizes and types as uniform list of addresses.

In C++, constant references can be used to obtain the immutable address of otherwise mutable variable. This allows to track easier where the variable could probably be modified. For instance, some startup code may set the variable, and the most of the program only see a constant reference to it, making sure the variable cannot be modified any further.

Answer 6

The different levels of const-ness are vital to lower levels of systems programming. The important distinction in systems programming between a compile time constant and an immutable variable relates to performance, the programmer's intent, and safety in the presence of external effects. Two prominent examples, Rust and C, make this distinction, and in more or less the same way.

Actual compile-time constants (that definitely are)

C has #defines that can effectively be considered direct textual substitution — copy and paste, if you like. Rust's consts are the same, except they're typed. It is useful to consider that Vec::new() is const!

Why is creating a dynamically growable array const though? Because a vec does not allocate when it's created. There are no runtime side effects at this point. The data structure that makes it up can be populated with the platform's equivalent of a null pointer and zero length entirely at compile time. This leads to confusion over this kind of code:

const CONST_VEC: Vec<String> = Vec::new();

pub fn main() {
    CONST_VEC.push("Hello".into());
    CONST_VEC.push("world!".into());
    dbg!(CONST_VEC);
}

The output of this is:

[src/main.rs:7] CONST_VEC = []

Why? Because this code effectively copy-pastes Vec::new() into each place where you see CONST_VEC. That's what a compile time constant is, a straight up substitution of compile-time-computable values. (You get warnings about this. Just to be clear. Rust knows you're doing something silly here.)

The point of this kind of copy-paste constant is simply to reduce repetition and document intent by naming, without compromising on the performance gains of static program parameters. Repetition of literals is bad because each repetition is the site for a potential mis-copy. Make the infallible machine do the copying! Naming is good, because identical literals may have different purposes, and a simple find-and-replace does not know that. Tell the fallible human which number to replace when a requirement changes!

Immutable variables (that might not be)

In a lot of cases, yes, there is no difference. Indeed in C++ a static const that is not also volatile can be treated the same as a #define or Rust const — a copy-paste. (Someone please correct me if I'm wrong, I'm not nearly as familiar with C++.)

But. In both Rust and C, their respective immutable variables can change, even within the lifetimes of the bindings. This is not some quirk or hackery, it is not unsafe, it is by design. The "immutability" is thus about what the programmer intends and declares, not the data itself.

In Rust, a non-mut variable can change due to interior mutability eg. using one of the UnsafeCell-derived types. You might regard this as a technicality or escape hatch, but interior mutability, and more importantly safe interior mutability, is a fundamental part of Rust's goal of combining usefulness and safety. UnsafeCell might expose an unsafe API, but there are plenty of safe interior mutability wrappers in Rust's stdlib eg. RefCell and Mutex.

In C, a const volatile variable is perfectly valid. What does it mean for a variable to be both const ("does not change") and volatile ("can change outside of operations known to the compiler")? One of those mental models must be wrong, and it's the first one. const simply means that the programmer, the human typing the word const, is declaring that they will not need to write code that directly changes it. The C compiler can enforce this. If the variable is not also volatile, the compiler can also make decisions about optimisations (reordering, combining, even total elision). If it is volatile, the compiler can only (but still) enforce the intent declared by the programmer.

Examples of where this commonly applies, in both languages:

• hardware exposed as a read-only memory-mapped peripheral eg. a UART receive buffer
• data crossing foreign function interface (FFI) boundaries
• data shared across thread or process boundaries.

---

Embedded and OS programming (for example) depend upon:

• having practical support from the language to simultaneously...
  • constrain what the programmer can mutate...
  • while accounting for the presence of externally driven side effects;
• achieving high performance by exploiting knowledge of program parameters

Taking a higher view then, these different levels of const-ness exist because of the intersection of requirements that are especially common in (although not exclusive to) low-level applications.

Answer 7

This is an old question with many good answers but in a quick survey of them I think none mention a particularly important difference between constants and readonly variables.

In C#, named constants must semantically be constant, forever. Why is that? Because the compilation model of C# assumes that constants are constant forever. Let me illustrate how this goes wrong. Suppose you have two assemblies, Alpha.DLL and Bravo.DLL, where Bravo has a dependency on Alpha. In the source code for Alpha, you somewhere have

public const string AlphaCopyright = "Alpha Software Copyright 2024";

If Bravo somewhere in it has

Console.WriteLine("Bravo uses Alpha Corp software");
Console.WriteLine(Alpha.Whatever.AlphaCopyright);

then when Bravo is compiled, the compiler copies the constant value into Bravo.DLL. It does NOT generate code that looks up the value in Alpha.

Now suppose some user out there has a copy of Bravo.DLL and Alpha.DLL, but they update their version of Alpha.DLL to a version that has

public const string AlphaCopyright = "Alpha Software Copyright 2024-2025";

then when they run code in Bravo, it still has the original copyright notice from when it was compiled. It does not pick up the new one, even though from reading the source code, it looks like it should be picking up the latest from whatever version of Alpha is installed.

The compiler assumes that anything marked const will never change even in future versions of the source code, and optimizes accordingly, so if a value could possibly change at some point in the future then mark it as readonly, not as constant, or make it a readonly property. Alpha's developers should have declared this as a property, not a const.