diff options
Diffstat (limited to 'exercises')
| -rw-r--r-- | exercises/067_comptime2.zig | 71 |
1 files changed, 33 insertions, 38 deletions
diff --git a/exercises/067_comptime2.zig b/exercises/067_comptime2.zig index 79f4335..38effe9 100644 --- a/exercises/067_comptime2.zig +++ b/exercises/067_comptime2.zig @@ -1,55 +1,39 @@ // -// Understanding how Zig treats numeric literals is fundamental -// and important, but it isn't exactly exciting. +// We've seen that Zig implicitly performs some evaluations at +// compile time. But sometimes you'll want to explicitly request +// compile time evaluation. For that, we have a new keyword: // -// We're about to get into the cool wizard stuff that makes -// programming computers fun. But first, let's introduce a new and -// vital Zig keyword: +// . . . o . . * . . . +// . * | . . . . . . * . . +// --o-- comptime * | .. . +// * | * . . . . --*-- . * . +// . . . . . . . . . | . . . +// +// When placed before a variable declaration, 'comptime' +// guarantees that every usage of that variable will be performed +// at compile time. // -// comptime -// -// When you put 'comptime' in front of a variable declaration, -// function parameter, or expression, you're saying, "I want Zig -// to evaluate this at compile time rather than runtime." -// -// We've already seen that Zig implicitly performs certain types -// of evaluations at compile time. (Many compilers do a certain -// amount of this, but Zig is explicit about it.) Therefore, -// these two statements are equivalent and using the 'comptime' -// keyword here is redundant: -// -// const foo1 = 5; -// comptime const foo2 = 5; -// -// But here it makes a difference: +// As a simple example, compare these two statements: // // var bar1 = 5; // ERROR! // comptime var bar2 = 5; // OKAY! // -// 'bar1' gives us an error because Zig assumes mutable -// identifiers will be used at runtime and trying to use a -// comptime_int of undetermined size at runtime is basically a -// MEMORY CRIME and you are UNDER ARREST. -// -// 'bar2' is okay because we've told Zig that this identifier -// MUST be resolvable at compile time. Now Zig won't yell at us -// for assigning a comptime_int to it without a specific runtime -// size. +// The first one gives us an error because Zig assumes mutable +// identifiers (declared with 'var') will be used at runtime and +// we have not assigned a runtime type (like u8 or f32). Trying +// to use a comptime_int of undetermined size at runtime is +// a MEMORY CRIME and you are UNDER ARREST. // -// The comptime property is also INFECTIOUS. Once you declare -// something to be comptime, Zig will always either: -// -// 1. Be able to resolve that thing at compile time. -// 2. Yell at you. +// The second one is is okay because we've told Zig that 'bar2' +// is a compile time variable. Zig will help us ensure this is true +// and let us know if we make a mistake. // const print = @import("std").debug.print; pub fn main() void { // // In this contrived example, we've decided to allocate some - // arrays using a variable count! - // - // Please make this work. Please? + // arrays using a variable count! But something's missing... // var count = 0; @@ -66,4 +50,15 @@ pub fn main() void { var a4: [count]u8 = .{'D'} ** count; print("{s} {s} {s} {s}\n", .{a1, a2, a3, a4}); + + // Builtin BONUS! + // + // The @compileLog() builtin is like a print statement that + // ONLY operates at compile time. The Zig compiler treats + // @compileLog() calls as errors, so you'll want to use them + // temporarily to debug compile time logic. + // + // Try uncommenting this line and playing around with it + // (copy it, move it) to see what it does: + //@compileLog("Count at compile time: ", count); } |