If the nogc marker could be used to overload functions then Phobos may include both versions of the code - GC and non GC - as some code may run faster under GC. The calling function would pick up the right one.

I can't imagine how this would work without over-complicating the syntax. Any ideas?

There should also be a way of compiling without a GC and making functions that require GC (those without the marker) compile-time errors, something like a build-flag like unittest or version. If the function can be made to not use GC, but there's a performance hit, then an alternate implementation could be provided.

But I still think it's valuable to mark which functions in the standard lib don't require GC (similar to why @safe and pure exist). This would would benefit game designers now, and make writing code to run on the bare metal easier. This is a major pain point for me with Go, because Go has no way of manually managing memory within the Go memory space, so bare-metal applications cannot be developed currently in that language. This is where D can step in and unseat C/C++ for that application.

Reply via email to