Was: Re: Vote for std.process

[Vladimir Panteleev]

On Friday, 12 April 2013 at 13:39:38 UTC, Manu wrote:
> If allocating a string on the stack makes it buggy, then there 
> is something
> really wrong. It should be no less convenient if appropriate 
> helpers are
> available.

Please see my reply to your other post.

> With consideration to the string[string] argument, surely 
> instances like
> that can be reconsidered? How is string[] going to produce more 
> bugs than
> string[string]?

env ~= "FOO=BAR";

This will probably not do what you want if there was already a 
line starting with "FOO=" in env.

An array of strings is a less direct representation of the 
environment than a string map. Certain common operations, such as 
finding the value of a variable, or setting / overwriting a 
variable, become more difficult.

> You're being paranoid, or sensationalising the effect of simple
> optimisation.

Strong words...

> And
> again, speed is not my concern here, it's inconsiderate the 
> allocation
> policy.

> I'm interested in eliminating allocations. It's just another 
> function that
> can't be called in a no-gc area. If it used the stack for its 
> temporaries,
> no problem.

Why allocations, specifically, if not for the performance costs 
of allocation and garbage collection?

> Can you describe the 'costs'?

See my previous posts in today's discussions.

> As much is convenient without causing you to start obscuring 
> your code?
> That's my personal rule.
> But I make it a habit to consider efficiency when designing 
> code, I never
> retrofit it. I tend to choose designs that are both simple and 
> efficient at
> the start.

OK, so if I understand you correctly: you would like Phobos to 
adopt a policy of avoiding heap allocations whenever possible, 
and this argument applies to std.process not because doing so 
would result in a tangible improvement of its performance or 
other metric, but for the purpose of being consistent across 
Phobos. Assuming that the language can provide or allow 
implementing suitably safe abstractions for doing so without 
complicating the code much, I think that's a goal worth looking 
forward, and we have been doing so for some time (hence the 
pending allocator design).