On Friday, 12 April 2013 at 17:41:59 UTC, Walter Bright wrote:
> On 4/12/2013 7:05 AM, Manu wrote:
>> I'll start doing it myself, but I also suggest it be made a policy, and
>> carefully considered when considering acceptance of ANY new module. That way,
>> new code that suffers the unpredictable/"surprise!" allocation problems won't be
>> introduced.
>
> I would also expect that Phobos modules that know the lifetimes of their allocated data use malloc/free rather than the gc.
>

Why not use GC.free ? malloc is invisible for the GC, so nothing GCed can be stored there safely.

On Friday, 12 April 2013 at 17:41:59 UTC, Walter Bright wrote:
> I would also expect that Phobos modules that know the lifetimes of their allocated data use malloc/free rather than the gc.

Or even better use new/delete. Delete also nullifies the pointer.

On 13 April 2013 03:51, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> On Fri, 12 Apr 2013 13:37:50 -0400, Walter Bright < newshound2@digitalmars.com> wrote:
>
>  On 4/12/2013 5:52 AM, Manu wrote:
>>
>>> Just to be clear, I'm not arguing optimisation for performance here, I'm
>>> arguing
>>> intolerance for __unnecessary__ allocations as a policy, or at least a
>>> habit.
>>> There's a whole separate thread on the topic of fighting unnecessary
>>> garbage,
>>> and having the ability to use D with strict control over the GC and/or
>>> allocation in general.
>>>
>>> If std functions have no reason to allocate, why should they?
>>>
>>
>> Absolutely right. All phobos functions should not allocate unless absolutely necessary.
>>
>
> Define "absolutely."  For example, there was an objection to accepting an AA as an "environment" map to std.process.spawnX functions because even though reading the AA would not require allocation, allocation would certainly be required to build the AA.  Is that acceptable?  Certainly we could invent a new non-allocating map type and accept that instead.
>
> I think we need clearer lines drawn here, if they are to be respected.
>

Great! I was raising the issue, with the intent to open it for discussion.

I never said an AA was intrinsically bad, only that it was impossible to call the function with an environment without allocating, ie, there is no way to pass a literal, and it's just being parsed and piped straight through to a system call, seems redundant to me.