[mhh__]

It won't compile.

You can also make it so it will compile but won't collect unless you ask it to explicitly.

We don't exclusively market to C++ developers. D replaced PHP and Java for quite a few D users.

[dataflow]

It won't compile, and... how is that a solution? You've basically told some users they can't use your language in that case. That's problem solved?

If you see PHP and Java replacement as taking off, that's awesome. I was addressing those who want to see it replace C++.

[mhh__]

The express purpose of the @nogc attribute is to enforce that code under it's influence doesn't use the GC.

There is lots of @nogc code available to depend upon

[dataflow]

> There is lots of @nogc code available to depend upon

That's not sufficient here. You can literally have a billion @nogc libraries, and even if there was one single GC-requiring library that many people want to use, the problem would be still there.

The only way to make this work is to ensure all of the libraries most people want to use work fine without a GC (or have @nogc alternatives that people would actually want to use). While not theoretically impossible, practically speaking, that's incredibly hard to pull off when you have a shiny GC sitting there.

[dymk]

In practice, "lots" isn't good enough. The whole ecosystem should work, not just lots.

[mhh__]

In practice (I.e. actual practice that pays my rent) it's been good enough for me

[dymk]

Then why did D get lapped by Rust if @nogc is good enough and the ecosystem is good enough?

If the answer is along the lines of "corporate backing", why did Rust get corporate backing and D didn't?

[mhh__]

Rust did memory safety better than D did, which was a very attractive prospect and then Rust was also lucky enough to get a following of people who very noisy about it.

Also in a world where JavaScript (excel, even) is dominant let's not ascribe these things to purely rational factors.