D on next-gen consoles and for game development

[Piotr Szturmaj]

W dniu 23.05.2013 20:13, Brad Anderson pisze:
> @nogc comes to mind (I believe Andrei mentioned it during one of the
> talks released). [1][2]
>
> 1: http://d.puremagic.com/issues/show_bug.cgi?id=5219
> 2: http://wiki.dlang.org/DIP18

When I started learning D 2 years ago, I read on the D webpage that D
allows manual memory management and it's possible to disable the GC. My
first thought was that standard library is written without using GC.
This could be kind of lowest common denominator solution to the
problem. Later, I found it was only my wishful thinking. So, you can
disable GC, but then you can't reliably use the standard library.

Lowest common denominator has its own weaknesses, mainly it sometimes
sacrifices performance, as some algorithms may perform better using
managed slices for example, than using manually managed memory.

nogc attribute could be used to not only block GC, it could be used to
select between GC and non-GC code with the help of the overloading
mechanism. So, the programmer instead of writing one function, would
actually write two functions, one for the GC and one for manual memory
management - only if they need separete code. This will surely double
the effort for some functions, but certainly not for the whole library.
Majority of code doesn't need separete functions, mainly because it's
non allocating code. But some, like containers would surely need these
two "branches".

It would be inconvenient to do twice the work when writing programs,
but I'm not so sure it is when writing a library. And this is just
because it's a _library_, usually written once and then reused. I think
that double effort is not that discouraging in this case.

So, I'd kindly suggest to at least think about this. I'm proposing that
nogc functions could be overloaded similarly to immutable/const
functions.

The other idea is to divide threads into two thread groups: managed and
unmanaged. This is like running two programs together, one written in
D, and one written in C++. If we can run managed and unmanaged
processes separately, why not run two analogous "subprocesses" inside
one process. nogc could help with that.

Obviously, such thread groups must NOT share any mutable data. They
could communicate with some sort of IPC, or perhaps ITC -
std.concurrency comes to mind.

This kind of separation _inside one process_ could help many
applications. Imagine real time sound application, with managed GUI and
unmanaged real time sound loop. I know, everything is possible now, but
I'd rather wait for a safe and clean solution - the one in the D style:)