The new std.process is ready for review

[Chris Nicholson-Sauls]

On Sunday, 24 February 2013 at 19:45:26 UTC, H. S. Teoh wrote:
>
> Alternatively, use a version identifier:
>
> 	version = newStdProcess;
> 	import std.process;	// get new version
> 	-----
> 	//version = newStdProcess;
> 	import std.process;	// get old version
>
> Then once the old version has gone through the deprecation 
> cycle and is
> kicked out, the new code can just ignore version=newStdProcess 
> and
> always import the new version, and existing user code needs no 
> changes.
>

Would work just fine, *if* versions propogated across modules, 
which they do not. (And doing so creates new problems discussed 
to death and beyond in times past.)  But maybe you meant setting 
it at the command-line, which to be honest, was my first thought 
as well. The ensuing discussion baffles me.

How about this as a suggestion, even though I know it will never 
happen.

Release A:
  - New process module is available as 'future.process'
  - Old module remains available as 'std.process' but with a 
pragma(msg) warning users that it will go away next release. 
(It'd be even better to have a pragma(warn), actually.)
  - Old module is duplicated as 'past.process'

Release B:
  - New module is now 'std.process', but with a pragma(msg) 
reminding users to update code if they haven't already
  - Old module remains at 'past.process'

Release C:
  - New module remains at 'std.process' now with no special 
messages.
  - Old module remains at 'past.process' for the last time.

Ta, fricking, da.
We should have started a procedure like this ages ago for Phobos 
additions and rewrites. Not everyone is in a position to 
comfortably use pre-release compilers, so testing new code from 
git head is not an option for them. Further, this gives old code 
three whole releases before it's forced to update; that ought to 
be enough legacy support.

Legacy support is the devil.