Totally. Zig is neither a better C nor a better C++, but an entirely new (and better, IMO) concept for how low-level programming can and should be done. Zig is about as simple as C and as expressive and powerful as C++, but it doesn't follow either's design tradition (unlike Rust, which is very much in the C++ tradition), and should only be compared to either one by virtue of all three being low-level languages.

> Zig is neither a better C nor a better C++, but an entirely...

I agree with your point because zig has evolved, but I do think that it is important to note at least for historical purposes, that zig was created literally as a "better c", and a lot of decisions are made because of some specific pain point X or Y in c

What is C++ tradition? Is it that one does not pay for a feature unless one uses it? In practice C++ broke with that with exceptions and RTTI. Even Rust does adhere to it since its standard library assumes infallible allocations making one to pay for not relying on it in the form of having to write an alternative library.

In all low-level languages you don't pay for what you don't use; that's not a design tradition but a requirement of the domain. I'm talking about the tradition of a low-abstraction, low-level language that has many features so that, when it is read on the page it appears as if it were high-level.

That would be the case if one wasn't allowed to turn them off.

The standard library of C++ assumes exceptions and that dictates code style that, even if one assumes infallible allocations and disable exceptions, one gets suboptimal code. So even with exceptions off one pays the price either in the form of non-standard library or accepting non-optimal performance. And if one has to prepare for fallible allocations, then the standard C++ is of no use at all in practice.

I assume you aren't that comfortable with ISO C++, the standard does allow for failible allocations.

That is the role nothrow in placement new, and custom STL allocators as language tool.

Additionally plenty of APIs now have exception and error based versions with noexcept.

The fallible allocators require to use exceptions. There is no way to use, for example, C++ containers with fallible allocators and disabled exceptions.

But even with exceptions enabled fallible allocation in practice does not work. There was an article that made malloc to return null randomly. All tested C++ implementations crashed then because they allocated memory when generating exceptions.

Stop talking in circles and point out ISO C++20 sections then.

I am also curious to see how serious was that article.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p070... - this discusses a lot of issues with exceptions as in ISO C++ and concrete proposals to make exceptions cost-free. The section 4.3.5 discusses specifically memory allocations.

Including parts that relate to Linux, have nothing to do with C++ and apply to any programming language.

You also skipped the section where Rust in its present state doesn't has any kind of recovery, it just panics.

> So even with exceptions off one pays the price either in the form of non-standard library or accepting non-optimal performance.

Holy moving goalposts, batman!

The "don't pay..." thing has only ever applied to runtime, there nothing in there about not having to write more code yourself, etc.

(It's also a bit dubious in the first place. Chandler had a good talk about this at one of the CppCon's, IIRC. Can't be bothered to look it up, but it should be on YouTube.)

> Comptime's lazyness is a necessary feature and not an accident. This is how Zig can avoid having a macro system.

Can you elaborate on lazy analysis replacing the need for macros?

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.)

I'm not sure how my statement was a misunderstanding if you are confirming that function analysis is in fact lazy.

The misunderstanding lies in not realizing how lazy evaluation is an integral part of what makes comptime a useful tool and that removing it would break comptime horribly.

That seems a bit of an overstatement. Calls to sometimes-unavailable functions are but one of the many uses of comptime. It seems entirely possible that lazily-analyzed blocks or functions could be demarcated syntactically (eg. "lazy { }") and that the large majority of comptime evaluation would not need to be inside such a block.