[dataflow]

No, it's about pure D code. Some (many) people just don't want a GC in their program and that's why they use C++. If they switch to D, they'll have to put up with a GC if any of their dependencies needs one, and the probability of that being the case is... high.

[mhh__]

@nogc eliminates that risk.

The GC also doesn't run if you don't call it so mitigating it's downsides while keeping the good aspects isn't all that hard.

[dataflow]

You disable GC for the whole program? And what do you do when one of your dependencies relies on it? Just live with a memory leak?

Bear in mind you're simply not going to convince anti-GC folks that you can have the "good aspects" of a GC without the bad ones, and they're the folks you're trying to market to. To many C++ programmers the only good GC is one that is absent. You can tell them they're wrong all you want, but regardless of who's right, it's always been a losing battle.

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

[gavinray]

Aye, you can turn off GC entirely, for the whole program

There's even a mode of D that operates this way by default, "-betterC" meant to be a C replacement

The GC really is an entirety opt-in component.

I'd encourage you/other folks to give D an honest try, you might be surprised

[dataflow]

You're not understanding my point unfortunately. I never said you can't turn it off. I said if you do, and any of your dependencies expect it to be on, then you have a problem. (Yes, I have tried D. That's how I know this.)

[gavinray]

Ohhh, fair enough, yeah I see what you're saying.

Yeah you're boned in that case I think and that's a real problem that can pop up if you want full @nogc

EDIT: Maybe not based on Max's comment

D-Plug (Audio FX plugins) is one example of having to build up a dependency stack of @nogc compatible deps, a lot of that is in-house stuff.

Not impossible but it's a commitment, at which point you may as well use something else unless you REALLY want to use D, for sure.

[dataflow]

> a lot of that is in-house stuff.

That's exactly the issue. Having to reinvent every wheel you need just isn't a selling point.

[mhh__]

If you actually turn it off (as in GC.disable()) they won't know either way, it's just a memory allocator to them.