Another try at wording ex067

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);
 }

patches/patches/067_comptime2.patch

@@ -1,4 +1,4 @@
-54c54
+38c38
 <     var count = 0;
 ---
 >     comptime var count = 0;