5 ms·

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

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#L59-L76 https://github.com/ziglang/zig/blob/master/lib/std/os.zig#L5...

AndyKelley 6y ago
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.
- JacobCarlborg 6y ago
  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.
IgorPartola 6y ago
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.

AndyKelley 6y ago

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.

JacobCarlborg 6y ago
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.

IgorPartola 6y ago

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.