Hi,
I mostly just lurk around here, but occasionally I just can't
resist putting in my two cents. I really want to see D replace
C++ for AAA games (my industry) and allocators are really
critical to that. I think there's an elephant here that most of
the posts have been dancing around.
In C++ when you roll your own allocators (whether STL allocators
or some other interface) there is basically, only one set of
*semantics* to worry about - the classic C++/C pattern of
new/delete or malloc/free. This is actually much more
complicated in D where you have at least two different semantics:
1) C++/C style
2) Tracing/Garbage Collection
3) Region allocators and other oddballs
Consequences:
1) These semantics aren't really interchangeable. If, for
instance, a library is implemented with one of them in mind, it
can only be replaced by an allocator with the same semantics.
2) Tracing/Garbage Collection are required for whatever the
default allocator is and replacement allocator must implement
those semantics.
3) Its only possible to change (2) by hacking the runtime so that
any language features that rely on the GC cause errors.
The design Andrei has presents seems to *allow* the creation of
allocators with all of these semantics, but it doesn't seem to
answer the following questions:
1) Can semantics be enforced?
2) Can allocators with different semantics be composed?
3) Can different semantics for the default allocator be
implemented?
4) If so, how can I reconcile that with libraries that expect
different default semantics? A use case that I foresee for
something like this would be banning the use of GC in low level
engine code, but allowing it in higher level gameplay code.
5) Are any of these questions even relevant for this part of the
design or will we have to wait for the rest of it to know the
answers?
Thanks.
