The new std.process is ready for review

[Lee Braiden]

On Sun, 24 Feb 2013 03:46:32 +0100, Andrej Mitrovic wrote:

> > Ah but how can you guarantee we won't ever need a 3rd rewrite? It's
> always possible we might need one in the future.

I think you want to guarantee that it CAN be re-written, because existing 
code always becomes crufty, and even less wise as time goes on, as new 
requirements become obvious.

> It's also a problem if we have to start remembering version numbers for
> each module we import. E.g.:
> 
> import std.process2;
> import std.xml; // oops, did I mean xml2 maybe?
> import std.signals2;
> 
> It's going to be annoying using Phobos like that. I was going to suggest
> using version flags, but even that could be annoying, although that
> feature was practically invented for this kind of problem.

Agreed.  But I think the problem is that we're talking about changing 
individual modules' versions, within what should be a stable D API.

I would much rather see something like D1 = Phobos1, D2 = Phobos2, and 
some flag at the top of a file, like @d_version(2), to say which version 
your code expects/requires.

The compiler could then say one of:

* OK, I'm version 3, but I'll give you the v2 phobos --- probably through 
library code like "version(>= d3) { ... } else { ... }"

* Sorry, I'm version 2, and you need version 3.  You need a newer 
compiler.

* Potentially, it could say, "Sorry, I'm D version 6, and only support 
versions since D4.  To compile D1-D3 code, you need an older compiler."  
But I don't think this would be wise.


Do D compilers currently warn about using deprecated features?  If not, 
that would be a useful addition from this kind of version specification, 
too.


The main benefit of this is that, within D2, there would be a truly 
STABLE API.  You'd know whether you should go with Phobos's built-in 
stream library, say, or some third-party library, because there wouldn't 
be a new rewrite coming next week.  Either you're writing for D2, or 
you're writing for D3.  If D2 doesn't have it, then you find a third-
party lib that does.  If D3 has it, and you want that, then you check out 
the bleeding edge D3 compiler / libs, and hope it doesn't blow up.


-- 
Lee