Here's a more complex example. Suppose we want to initialize an array of squares:

    int[4] squares1 = [0, 1, 4, 9]; // doing it by hand

    int[4] squares2 = () {
      int[4] a;
      foreach (i; 0 .. 4)
          a[i] = square(i);
      return a;
     } ();  // doing it with CTFE

squares2 declares a lambda, which returns the initialized array, and then executes the lambda.

D sure looks like the language everybody "C++" actually wanted, if they only knew they wanted it.

I actually include myself in that camp, so thanks for taking the stage :D

The reason D didn’t really gain traction over the years was because it required a garbage collector. Recently it’s going the other direction via betterC (a mode where you can ditch the GC), but many parts of the standard library still require the GC to run properly.

C# hasn't had the same issues,

https://www.wildernesslabs.co/

https://nikolayk.medium.com/getting-started-with-unity-dots-...

Had Remedy experiment worked out, maybe DOTS would be using D instead of having their own compiler infrastructure for HPC#.

Nor Java even,

https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/wp/products-services/jamaicavm/

The main reasons are not having a big name company that would push D no matter what, and lack of focus where D should aim for.

D is a general purpose programming language, it does not aim at a niche.

It is called killer feature for market adoption.

Very, very little of the library requires a GC.

You can ensure your D code doesn't use the GC by adding the `@nogc` attribute.

But really, all this concern about the GC is misplaced. It's just another tool available. You can use it in D, or use RAII, or your own allocation system. It's your choice as a D programmer.

It is a shame that until now the software industry has not figure out how to reliably perform automatic memory management or GC. Unlike the auto industry the manual transmission is going to a dinasour route compared to the now default automatic transmission.

I am giving this analogy since Walter has a degree in mechanical engineering and he has correctly made the GC a default in D but not mandatory, but the choice somehow is not popular in the software industry.

Sadly it took too much time, and lost momentum. C++ version

    int squares1[4] = {0, 1, 4, 9}; // doing it by hand

    std::array squares2 = [] {
      std::array<int, 4> a;
      for (int i = 0; i < 4; i++)
          a[i] = i * i;
      return a;
     } ();  // doing it with CTF

Is as pretty? Not as much, but it does the job.

Ok, try this one:

    string cat(string s) {
        return "int " ~ s ~ ";";
    }

    int test() {
        mixin(cat("i"));
        return i + 3;
    }

For that one D gets one point, even though Circle C++ might be able to do it, it isn't ISO C++.

So what if D wins at code golf against C++?

What matters is being good enough for most compile time use cases, while enjoying the large ecosystem and IDE tooling, perfect is the enemy of good.

The ability to use CTFE to generate strings that can then be fed back into the compiler is a heavily used feature, not just a golf point. It enables the creation of mini-DSLs.

You tend to praise D features, while ignoring that a language on its own doesn't make an ecosystem.

Indeed C# and C++ don't give me all nice features from D, when doing language comparison tables, D wins on that table listing.

Yet they give me their library ecosystem, graphical IDEs, and first day avail on any major company SDK.

I will take that productivity win over the few features that the D language happens to have.

Why is Andrei Alexandrescu helping to improve C++ at NVidia instead of using D, when the language is so great?

Ecosystem, that is why.

Zig evaluates compile-time expressions using the semantics of the target, does D do that? (I genuinely don't know; not trying to "gotcha")

   const std = @import("std");

   export fn square(x: c_long) c_longlong {
       comptime std.debug.assert(@sizeOf(c_longlong) > @sizeOf(c_long));
       return @as(c_longlong, x) * x;
   }

If I run `zig build-obj` on that on my i9 Mac, compilation fails with an assertion error. If I run `zig build-obj -target arm-freestanding-gnu` instead, it compiles since sizeof(long) is 4 and sizeof(long long) is 8.

> does D do that?

Yes:

    c_longlong square(c_long x) {
        static assert(c_longlong.sizeof > c_long.sizeof);
        return cast(c_longlong)x * x;
    }

The thing that makes Zig comptime radically different is that types are comptime values, so you can make functions that take types as arguments and return new types as results - it's like C++ templates on steroids, yet conceptually simpler.

Well, D does, too:

    template MakePtrType(T) { alias MakePtrType = T*; }
    MakePtrType!int p;

    pragma(msg, "p is type ", typeof(p));

    dmd -c test2.d

    p is type int*

or perhaps I am misunderstanding you?

To be fair, now we're well out of the realm of CTFE. (Though that edges into the macros debate.)

You aren't returning the new type there, looks like you just inline that code. Zig lets you create and return new types that way while your example looks like just regular template substitution.

Edit: So the main difference seems to be that types are first class citizens in Zig, you can write a normal comptime function that returns a type and either use it to do more metaprogramming or everywhere you would declare a type for a function or variable. I am not aware of any static typed languages that lets you do this with normal language syntax.

C++ does it with templates, but in Zig you can do what C++ templates can but with if statements and loops.

Just use the Circle compiler and you have the full C++ language at compile time, available today.

It is returning a new type.

Please show me an example where it differs. D's metaprogramming is very good at constructing types. A member of the D community tried very hard to implement type functions, but it turned out to be redundant with D's existing capability.

If anything it is only a simpler syntax for C++ template meta-programming, not needed knowledge about SFINAE and tag dispatching tricks, most of which are anyway no longer required with the improvements made across C++17, 20 and 23.

It reminds me of Idris, where the types can actually run programs (at compile time) as long as they can be proved to terminate, which is more often than I though.