On 12 April 2013 18:34, Johannes Pfau <nospam@example.com> wrote:
Am Fri, 12 Apr 2013 17:04:08 +1000
schrieb Manu <turkeyman@gmail.com>:

>
> I've said before, I sadly have to avoid phobos like the plague. Some
> modules (like this one) that provide fundamental functionality - not
> just helper functions - can't be avoided. Requirements for those
> should be extra strict in my opinion.
>

Most (GC) allocations could be fixed without breaking the API. I can
see 2 places where the API forces _GC_ allocations:
* string[string]
* thrown Exceptions are allocated with the GC

There is no simple solution for these. Maybe we'll have a hashtable in
the standard library at some point which will allow to use custom
allocators. Then std.process could use these. Exceptions require some
thinking. You can of course allocate them using any allocator, but
freeing them is difficult...

Exceptions are exceptional, I don't think that's an issue.
the string[string] in the api is guaranteed garbage, and will never be changed. What's the advantage of using an AA in this case?

If you want to get rid of all (not only GC) allocations, there's another
issue: As D strings are not zero terminated we'll always have
allocations passing those to C code.

They are being passed through to a C function that doesn't retain the pointer; they can be allocated on the stack.

Maybe we should have a cstring
type in phobos which would just be a string which is guaranteed to be
zero terminated.

Maybe, although the point here is to wrap up and hide the C API, so that's not useful here. A helper in phobos for allocating a (c)string on the stack may be useful...