On Sunday, 24 February 2013 at 04:54:13 UTC, Jonathan M Davis
wrote:
On Saturday, February 23, 2013 19:47:54 Nathan M. Swan wrote:
Why not just deprecate everything currently in std.process and
drop in
the new stuff? It might be a bit ugly, but it prevents both
code
breakage _and_ a proliferation of "std.module2"s.
That only works if there are no conflicts and none of the
functions' behaviors
are changed in a manner which would be incompatible with how
they currently
work.
[...]
I don't know how much the new std.process
conflicts with the old one, but since the main fellow behind
the new one is the
same one who did the new std.path, I suspect that they conflict
to much to be
able to do the transition within a single module. I'd have to
compare them to
be sure though.
Let me save you the trouble. There are three points of
incompatibility between the old and the new APIs, that prevent
them from coexisting:
shell():
The old shell() captures the standard output, returns only a
string containing the output, and throws an exception if the
program returns with a nonzero exit code.
The new shell() only throws if there was an error with actually
running the process, it captures both the standard output AND
standard error streams, and it returns a tuple which contains
both the output and the exit code.
environment.opIndex():
The new version no longer throws if the environment variable does
not exist, it simply returns null. This is a very subtle change
that will not cause a compilation error.
It was I who wrote the old 'environment' as well, and the idea
was for it to have the exact same interface as the built-in
associative arrays. Therefore, at the time, it seemed like a
good idea to throw from opIndex(). However, having actually used
it for quite some time, I have found that I *never* want that
functionality. I *always* end up calling environment.get()
instead, to avoid the exception. Thus, I decided use this
opportunity to change it.
environment.get():
To distinguish it from opIndex(), the second argument (the
default value if the variable doesn't exist) is no longer
optional. This, however, will cause a compilation error in the
cases where the second argument has been left out, and all other
cases will work like they used to.
I would absolutely *hate* to have to change the name of shell(),
or, worse, revert it to the old version. I am reluctant to
revert environment.opIndex() too, as I would really like to get
it right this time. I am not going to be as adamant on this,
however. environment.get() is not a big deal, but if
environment.opIndex() changes, this might as well do too.
Lars
