Comment by ScottRedig | Hacker News Reader

Comment by ScottRedig | Hacker News Reader

Parent Full thread

Hello Mr. Bright. I've seen similar comments from you in response to Zig before. Specifically, in the comments on blog post I made about Zig's comptime. I took some time reading D's documentation to try to understand your point (I didn't want to miss some prior art, after all). By the time I felt like I could give a reply, the thread was days old, so I didn't bother.

The parent comment acknowledges that compile time execution is not new. There is little in Zig that is, broad strokes, entirely new. It is in the specifics of the design that I find Zig's ergonomics to be differentiated. It is my understanding that D's compile time function execution is significantly different from Zig's comptime.

Mostly, this is in what Zig doesn't have as a specific feature, but uses comptime for. For generics, D has templates, Zig has functions which take types and return types. D has conditional compilation (version keyword), while Zig just has if statements. D has template mixins, Zig trusts comptime to have 90% of the power for 10% of the headache. The power of comptime is commonly demonstrated, but I find the limitations to be just as important.

A difference I am uncertain about is if there's any D equivalent for Zig having types being expressions. You can, for example, calculate what the return type should be given a type of an argument.

Is this a fair assessment?

> A difference I am uncertain about is if there's any D equivalent for Zig having types being expressions. You can, for example, calculate what the return type should be given a type of an argument.

This is done in D using templates. For example, to turn a type T into a type T star:

    template toPtr(T) { alias toPtr = T*; } // define template

    toPtr!int p; // instantiate template

    pragma(msg, "the type of p is: ", typeof(p));

The compiler will deduce the correct return type for a function by specifying auto* as the return type:
auto toPtr(int i) { return cast(float)i; } // returns float
For conditional compilation at compile time, D has static if:
enum x = square(3); // evaluated at compile time static if (x == 4) int j; else double j; auto k = k;
Note that the static if* does not introduce a new scope, so conditional declarations will work.

The version is similar, but is intended for module-wide versions, such as:

    version (OSX)
    { stuff for OSX }
    else version (Win64)
    { stuff for Windows 64 }
    else
        static assert(0, "unsupported OS");

Compile time execution is triggered wherever a const-expression is required. A keyword would be redundant.

D's mixins are for generating code, which is D's answer to general purpose text macros. Running code at compile time enables those strings to be generated. The mixins and compile time execution are not the same feature. For a trivial example:

    string cat(string x, string y) { return x ~ "," ~ y; }
    string s = mixin(cat("hello", "betty")); // runs cat at compile time
    writeln(s); // prints: hello,betty

I'll be happy to answer any further questions

I appreciate you taking the time to give examples in D. People are often under the mistaken impression that Zig's compile time is revolutionary, from how it is excessively hyped, but are failing to realize that many other languages have similar or users can get similar results by doing things differently, because languages have different philosophies and design strategies.

For example, the creator of Odin, has stated in the past he rather come up with optimal solutions without metaprogramming, despite enthusiasts trying to pressure him to add such features into that language.

Reply on news.ycombinator.com