The new std.process is ready for review

[Steven Schveighoffer]

On Tue, 26 Feb 2013 10:47:40 -0500, Vladimir Panteleev  
<vladimir at thecybershadow.net> wrote:

> On Tuesday, 26 February 2013 at 15:26:50 UTC, Steven Schveighoffer wrote:
>> You mean changing as in, instead of throwing an exception, it tries to  
>> use a null value and segfaults?  Not a very significant difference.
>
> I'm still not following... where would the segfault come from? Unless  
> you dereference .ptr, you can't get a segfault from operating on a null  
> string.

It's funny, I completely forgot about that!  My brain was still in  
Objective-C/C++ mode :)

You are right, the difference is important.

>> But we are splitting hairs here.  The first one could potentially  
>> change the environment variable that the second uses, thereby affecting  
>> the behavior.
>
> That's a completely different matter from changing how code within the  
> same program accesses the environment in general. Both components may be  
> operating on specialized, prefix-named variables that have no chance of  
> interfering with each other, and still break when the behavior of a  
> global object changes.
>
> It would be safer for the component to define a very small wrapper,  
> which changes environment's semantics according to its requirements.

I was trying to come up with an equivalent to set -u.  In other words, you  
said "good scripts use set -u", you could equivalently say "good D  
programs use Enviroment.throwOnMissingData = true"

It was just a thought.

Another possibility (naming to be determined):

Environment.nthrow["x"]; // doesn't throw
Environment["x"]; // throws

At this point though, I think the discussion really is bikeshedding.   
Environment.get is not that much different than Environment[].  We should  
keep the current behavior in the interest of backwards compatibility.

-Steve