Lazyness is what allows you to write code that feels naturally coherent but that would be an error with eager analysis. As an example:

  switch(build.target.os) {
    .Linux => std.os.fork(),
    .Windows => std.os.funcUniqueToWindows(),
    else => @compileError("feature not supported for target os"),
  }

This a simplified example to say that each path that depends on a comptime condition, such as the target OS, for example, feels intuitively consistent but in Zig types can (and do) mutate depending on those conditions and if the compiler were to eagerly check dead branches it would find plenty of semantical errors. In the stdlib you can see how `os` corresponds to a different struct definition depending on the target: https://github.com/ziglang/zig/blob/master/lib/std/os.zig#L5...

This definitely does cause problems though; I want to acknowledge that. For example, right now we have an issue that auto-generated documentation does not include unreferenced globals.

I have some ideas to address this, but it does represent a flaw in the status quo design of the language.

In D, all semantic analysis is performed eagerly (I think), except for templates. D also supports CTFE (Compile Time Function Evaluation), `static if`, `static assert` and a few other language constructs that are evaluated at compile time.

I experimented a bit at how D's documentation generator behaves using these language constructs. Here's a snippet of some D code:

  /// some struct description
  struct Foo(T) // template
  {
      /// some alias description
      alias Result = int;
  
      /// some method description
      Result foo()
      {
          string a = 3; // this does not normally compile
      }
  
      static if (is(T == int)) // evaluated at compile time
      {
          /// some method description 2
          void bar() {}
      }
  
      version (Windows)
      {
          /// some method description for Windows
          void bazWindows() {}
      }
  
      else version (Posix)
      {
          /// some method description for Posix
          void bazPosix() {}
      }
  
      else
          static assert(false, "Unsupported platform"); // evaluated at compile time
  }

When generating documentation for the above code, and `Foo` has not been instantiated, the generated docs will include `Foo`, `Result`, `foo`, `bar`, and `bazWindows`. This is regardless of platform. The return type of `foo` will be `Result` and not `int`. This clearly shows that the D compiler doesn't perform semantic analysis when generating documentation. When doing a regular compilation and `Foo` is instantiated, `bar` will only be included if `T` is an `int`. `bazWindows` will only be compiled on Windows and `bazPosix` will only be compiled on Posix platforms.

Looking at the implementation, the compiler will generate the docs after semantic analysis and only if there are no errors. But, if `Foo` is never instantiated no errors have occurred so it will continue to generate the docs.

On the other hand, if `Foo` is instantiated (and compiles) the compiler will generate docs for the AST after semantic analysis has been performed and `bazWindows` will only be included if the docs were generated on Windows and `bazPosix` will only be included on Posix platforms. What's weird though, is that it seems `bar` will be included regardless of what type `T` is.

But you can still check the syntax of that statement without evaluating it all. You might even be able to check if things like std.os exist.

C macros are lazy, but they also operate at the level of lexical tokens instead of the AST, which means you can use macros to generate C code, but you can't really do it in a way that is guaranteed to be safe.

With Zig you can have a function where some or all arguments are marked as "comptime", which means the values for those arguments must be known at compile time. Combined with the fact that types can be used as values at compile time means that you can use Zig to generate Zig functions in a safe way.

I'd appreciate some elaboration on that too. It sounds vaguely similar to SFINAE in C++, but I don't know enough about Zig's compilation model to know for sure.

(I'm vaguely familar with Zig from a talk by the creator about 1½ years ago, fwiw.)