[dataflow]

Yeah, I'm pretty sure it's the reason many C++ folks reject it. It's kind of ironic that having the "wrong" useful feature can hurt you, but that seems to be what's happening here. I feel like they might actually have a shot at solving it by literally dropping GC support, but it's hard to say at this point. I don't know if the standard library still has anything that needs a GC, but making sure that's not the case might be a good first step if they're ever interested in going in this direction.

[funnymony]

Conveniences like closures depend on gc

[Kukumber]

That's not true

https://dlang.org/spec/function.html#function-pointers-deleg...

[dataflow]

C++ has had closures without a GC for over a decade now.

[pjmlp]

As syntactic sugar for how C++ functors used to be implemented, and they also bring their own set of issues when interoperating with co-routines.

[dataflow]

If anything that's a statement about coroutines, not closures. And even then, not every coroutine has problems. I don't see a logical implication from that to a GC requirement.