const is not what you think!

Ajouté : 2026-05-03

[00:00:00]Well, this is a variable, and as you probably already know, you can change its value after declaring it. And this is also a variable, but it can only be assigned at compile time. Think of it as a variable that only lives during compilation. However, this one is a constant, meaning you can't reassign it after initialization. And this is also a constant, but it's a constant that only exists at compile time. So, the real question is, what's the difference between a constant and a compile time constant? And why do languages like Zig and C3 explicitly support the com time concept, along with C++ through its own constant expressions, while other low-level languages like C, Rust, and Odin just use constants or other ways to handle those cases instead?

[00:00:45]Good morning, everyone. I hope you're all doing well. I just spent the last night thinking and researching about everything you saw in the intro. So, let's theoretically answer those questions and try to figure out what com time even means in Mine while answering.

[00:00:58]But before I start, I want to make something clear.

[00:01:01]I don't follow anyone's rules but my own. That means I'm redefining everything from scratch. I'm giving everything a name, a function, and a clear purpose. I don't want Mine to be just another copy of existing languages.

[00:01:12]All I'm trying to build is something good, something fast and clean, something that doesn't make me hate programming. That's it. Nothing more, nothing less. However, before we talk about constants, we need to understand variables first, what they are, how they work, and where they live. And please don't skip this part just because you already know the basics because everything coming up in this entire series and in Mine itself will be built on the decisions I'm about to make. So, let's start.

[00:01:38]All right. Variables are a way to store a value and control it throughout the variable's lifetime, within the program's lifetime. And please don't confuse the variable's lifetime with the program's lifetime. A variable's lifetime starts when it's declared and ends at the last place it's used. And that usage must be within a scope that has access to that variable. But the program's lifetime, on the other hand, starts from the moment the program begins and ends when it completely terminates. Anyway, we've already talked about all of this before, but what I want to focus on this time is actually not the variables themselves because as we know, variables and constants are two sides of the same coin. What they have in common is the content itself. So, if we truly understand where a value comes from and where it goes, only then can we understand the difference between a constant and a variable. In Mine, the value always comes from expressions. For example, when we write 1 + 2, that's a binary expression that adds two numbers and returns a value. The variable takes that value and temporarily stores it somewhere until it's needed or used. But I want you to imagine you have a function that fetches information from the internet at runtime. If we try to call that function and store its value in a variable, will it store that value in the same place it stored the simple value produced by the binary expression?

[00:02:56]The answer is simply yes. There's actually no difference between the variable in the first example and the variable in the second example. The only difference is the value itself, and even that isn't really a big difference. In the first one, we used a binary expression to produce a value, and in the second, we also used an expression, but just a different kind, one that calls a function. But at the end, it's still an expression, and what we expect from any expression is exactly one thing, a value.

[00:03:22]Anyway, what matters here is what happens to the value after it's produced by the expression. Where does it go? And that's where we reach the central question of this episode, the one that once answered will finally let us understand everything I've talked about so far. Where does a program store its data? And if it has more than one place to store data, like a random access memory or a hard disk, for example, what are the rules or conditions used to decide where that data should go? What's the difference between storing data in random access memory versus storing it on the hard disk? Does that affect how fast we can read it? Can we control data regardless of where it's stored? And is the way we read data the same in all cases, or does it change depending on where it lives?

[00:04:03]Actually, that's a lot of questions. To answer that, we need to understand what actually happens between the moment you write code and the moment it runs.

[00:04:12]Step one, you write code, just text, nothing more. The compiler's job is to take that text and turn it into something the machine can actually execute. Step two, the compiler builds a binary. The output is a file. On Linux, it's called an ELF file, executable and linkable format. But on Windows, it's a PE file, different name, but same idea.

[00:04:33]This file is not just your code dumped into a file. It's a structured container organized into sections, each with a specific purpose and specific rules about what can be done with it. We have four main sections. Firstly, the text section, which is your actual code, the compiled instructions, read-only, executable. The operating system loads this once and never modifies it.

[00:04:55]Secondly, the read-only data, the constants whose values are known at compile time and never change. If you try to write to this, the operating system kills the program immediately.

[00:05:06]After that, we have the data section for initialized global and static variables, and also for values that are known at compile time but can change at runtime, read and write, not like the read-only data section. And finally, the BSS section for uninitialized global and static variables. It doesn't even take up space in the binary file itself. The operating system just allocates zeroed memory for it at runtime. Also, there's the stack and heap, but those don't exist in the binary at all. They're created at runtime in the random access memory while the program is running.

[00:05:37]Step three, you run the program. The operating system reads the binary file from disk, but the CPU can't execute code directly from disk. Disk is too slow, and the CPU doesn't work that way.

[00:05:49]So, the operating system loads the relevant sections into the random access memory.

[00:05:55]Text loaded into memory, read and execute. Read-only data loaded into memory, read only. Data loaded into memory, read and write. BSS allocated in memory as zeroed memory, read and write.

[00:06:07]Then the stack gets created in the memory for local variables and function calls, and the heap is reserved in the memory for dynamic allocations. But why random access memory and not just read from disk directly? Simply because random access memory is orders of magnitude faster than disk. The CPU needs to read and write data constantly.

[00:06:27]Reading from disk every time would make every program unbearably slow.

[00:06:32]Random access memory is the CPU working space.

[00:06:35]However, if we look at this table, we can see exactly where each element is stored, whether in the binary or in the random access memory. Feel free to pause and read through it. But what I really want to focus on is the last item. If you write const X = 5, and the compiler knows the value at compile time, it might not put X anywhere. It just replaces every use of X with 5 directly in the instructions. X never exists as a separate thing. And that's exactly where const and com time const start to diverge. As for constants, the compiler might inline it or put it in the read-only data section or put it on the stack. You don't fully control which.

[00:07:12]The compiler decides. But for com time constants, you're telling the compiler explicitly, you must know this at compile time, which means it either gets inlined into the instructions or goes into the read-only data section. It will never live on the stack. It will never be computed at runtime. And that distinction between known at compile time and computed at runtime is exactly what the rest of this episode is about.

[00:07:43]Well, now we have everything we need. We know what a variable is. We know what a constant is. We know where data lives, in the binary, in the random access memory, or nowhere at all if the compiler inlines it. So, now let's finally answer the question. In Mine, there are four ways to declare a value.

[00:08:00]Let's go through each one. Firstly, the variable. You already know this. The value lives in RAM. It can change, and it exists at runtime. As for the constants, also lives at runtime, but you can't reassign it after initialization. Depending on whether the compiler can figure out its value at compile time, it either gets inlined into the instructions, placed in the read-only data section, or put on the stack. You don't fully control which.

[00:08:24]The compiler decides. After that, we have the com time variables. This one is different. This value does not exist at runtime. It only exists during compilation, while the compiler is building your program. You can change it during that process, but the moment compilation is done, it's gone. The machine never sees it. But when would you use this? Well, I think when you need to compute something step by step at compile time, like building a lookup table, counting items, or accumulating a result, and you need the value to be mutable while you're doing it. And finally, the com time constants. Same idea, but immutable. You set it once at compile time, and it never changes, not during compilation and not at runtime because it doesn't exist at runtime.

[00:09:06]This is the one you'll use most. Array sizes, type parameters, fixed configuration values, or anything that needs to be known at compile time and will never change.

[00:09:20]Well, if you were paying attention throughout the episode, you might have noticed I left a few questions on screen, things that came up naturally and I didn't want to skip over. So, let's answer them quickly. Firstly, what if I have a 100 GB game? Doesn't that mean everything gets loaded into RAM?

[00:09:35]This one is actually fascinating. The operating system doesn't load the entire binary into RAM at once. That would be a disaster. Instead, it uses something called virtual memory and demand paging.

[00:09:47]It only loads the parts the program actually needs right now. When you open a 100 GB game with 16 GB of RAM, only the current level gets loaded. When you move to the next one, the operating system loads the new data and removes what's no longer needed. When a program asks for something that isn't in RAM yet, the operating system quietly fetches it from disk in the background.

[00:10:07]This is called a page fault and it happens constantly without you ever noticing. And if RAM fills up completely, the operating system moves parts that aren't being used to disk temporarily to make room. That's called swap. So, the short answer, the operating system lies to your program.

[00:10:23]It tells it "You have all the memory you need." and then quietly manages what's actually in RAM and what's sitting on disk behind the scenes.

[00:10:32]Now, as for the second question, what if I write this Boolean constant and then take its address? We said compile time constants might get inlined, meaning they don't exist anywhere in memory. But the moment you write ampersand followed by the constant name, you're asking for its address and you can't have an address for something that doesn't exist. So, the compiler's forced to materialize it. It places X in the read-only data section, gives it an address, and XP points to that address.

[00:10:59]The value is still immutable. You still can't write to it. But now, it has a real address in memory. Now, you might be wondering why I used a Boolean type here instead of an integer type, for example. And that's actually worth explaining. In Mine, if you write this, Mine doesn't infer this as an int or float or any concrete type. It infers it as comp time int. Same thing for floating-point numbers. Mine infers them as comp time float. These are not real types that live in memory. They're just literal values. The compiler sees them, uses them wherever they're needed, and inlines them directly into the instructions. They never get a memory address. So, if you tried this, you will get two issues. Firstly, what type do you even put for the pointer? Comp time int? That's not a real type at runtime.

[00:11:43]And secondly, X doesn't exist in memory, so there's no address to give you. The compiler will refuse. But the moment you add a type annotation, you're telling Mine, "I don't want a literal. I want a real value in memory." And now it has an address. So, the rule is comp time int and comp time float are literals, not values. They get inlined. They have no address. If you need an address, you need a concrete type. However, before we move on, something in this line caught my attention. There are two const keywords here. And since this whole episode is about const and comp time, so let's clear this up quickly. The first const means XP itself can't be reassigned. You can't point it somewhere else after this line. But the second const means the value being pointed to can't be changed through this pointer.

[00:12:28]You're not allowed to write to whatever address this pointer holds. So, they're answering two completely different questions, two different things. The first one is about the pointer and the second is about what it points to.

[00:12:44]Well, one last thing before we close out this episode. We've been talking about comp time as something you put in front of variables and constants, but that's not the whole picture. Comp time in Mine is actually more flexible than that. It has two forms. Firstly, as a modifier.

[00:12:58]You already know this one. You put comp time in front of a declaration and it tells the compiler, "This must be known at compile time." You can also use it on function parameters, telling the caller that this argument must be a compile time known value. Also, you can use on an entire function, forcing the function itself to run at compile time. Secondly, as an expression. This is where it gets interesting. You can wrap any expression in comp time and force it to be evaluated at compile time, even if it looks like a normal runtime call. And this means that we can use it freely with function calls or with if-else conditions or other expressions. And that's the full picture of comp time and constants in Mine. It's not just a keyword for declarations. It's a way of telling the compiler when to do its work. And the earlier it works, the less your program has to do at runtime.

[00:13:48]That's all for today. Make sure to subscribe, like, and leave a comment to motivate me. And if you're watching this episode in the first week, support the channel with hype. Thanks for watching and see you next time.

[00:14:04]Oh, I almost forgot.

[00:14:05]If you're interested in building your own Claude from scratch, step by step in your own programming language, you can try that for free right now. And it's not just Claude. You can also build your own Git, your own Redis, or if you're into networking, so your own DNS and HTTP servers from scratch. There's a lot more to explore beyond that. However, unlike the Claude project, the rest requires a subscription. I'll leave a link in the first comment with 40% off for all plans. Good luck.