Another try at wording ex067

This commit is contained in:
Dave Gauer 2021-04-16 22:15:27 -04:00
parent bf861f71f7
commit 0c9ebd941c
2 changed files with 34 additions and 39 deletions

View file

@ -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.
// 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.
//
// '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 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);
}

View file

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