The new std.process is ready for review

[Steven Schveighoffer]

On Tue, 26 Feb 2013 07:28:11 -0500, Vladimir Panteleev  
<vladimir at thecybershadow.net> wrote:

> On Tuesday, 26 February 2013 at 07:08:37 UTC, Lars T. Kyllingstad wrote:
>> What if the variable is set, but empty?  Is that very different
>> from the situation where it doesn't exist at all?  In my opinion,
>> when it comes to environment variables, no.
>
> Until today, I didn't know that empty variables could exist. They don't  
> exist on Windows: setting a variable to an empty string is how you  
> delete it.
>
> Regardless, I think my point still stands on the argument that it's much  
> more likely for a variable to be unexpectedly unset rather than  
> unexpectedly empty. To extend to a general case, we could say that an  
> empty variable is as likely as any invalid or unexpected value. For the  
> 'rm -rf $FOO/$BAR' case, one can come up with any combinations of FOO  
> and BAR, such as "/bin" and "../", where the command would have the same  
> effect.

If I use $XYZ in a script, and XYZ isn't set, it equates to nothing.  When  
I use getenv, it returns null.  That is the behavior I would intuitively  
expect.

On one hand, I think the correct behavior is to return null, and let the  
program deal with checking the error, or use get if they have a default.   
If we throw an exception, people will end up catching the exception in  
order to avoid an unintended error.  Exceptions are not good for flow  
control, they are for exceptional situations that you didn't plan for.

On the other hand, the other implementation, which is already in  
std.process, is also a valid implementation, and there already exists code  
which uses it.  If we have the same abilities via get, then no  
functionality is lost, it's just a tad more verbose.

In my opinion, the current implementation is only slightly worse than the  
proposed.  If there is a chance we can simply replace std.process instead  
of using std.process2 if we go with the original implementation, I think  
we should do that.

-Steve