On Tue, 26 Feb 2013 10:47:40 -0500, Vladimir Panteleev
<vladi...@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
