The new std.process is ready for review
Chris Nicholson-Sauls
ibisbasenji at gmail.com
Sun Feb 24 11:55:58 PST 2013
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.
More information about the Digitalmars-d
mailing list