Why are the exec* functions deprecated in std.process?

[Andrei Alexandrescu]

On 10/29/13 11:16 AM, Lars T. Kyllingstad wrote:
> Since I was the one who added the deprecation notices, I guess I'll have
> to answer for it. :)

Great, thanks.

> The main rationale for removing them was that I considered them to be
> low-level, rarely used functionality.  Most applications *by far* will
> use the "spawn" style of process creation.

That would be reason to not add, not to remove. They're there, and I 
must use them, otherwise my D code is 10% slower than the equivalent C++ 
code, in a project at work in which speed is of the essence. Why do I 
need to resort to the C functions?

> While I have no statistics to back this statement with, the very fact
> that std.process went through several reviews on this forum and the
> Phobos mailing list, and even went into active use by some people (and
> one notable project, vibe.d) long before its inclusion in Phobos,
> without these functions being mentioned even *once*, is testament to its
> accuracy.

It's been indeed reviewed, and I followed the reviews and was glad to 
see people liked it. My understanding was it was a backward compatible 
(within reason) revamp of std.process. It honestly didn't occur to me to 
go and see whether essential existing functionality has been deemed 
deprecated.

> To me, these functions simply fall on the wrong side of the
> usefulness/bloat line.

On usefulness: "Objection, your honor" :o). Forwarding from one process 
to another is an essential part of process control. Loading another one 
and waiting until it's done is a very wasteful way to replace it. And I 
do recall the std.process revamping took pride in being more efficient 
than the old one.

On bloating: the module std.process defines a couple dozen symbols. It's 
very far from bloating, and unlikely to grow because OSs are fairly 
stable when it comes to process control. Bloating doesn't strike me as a 
valid argument for removing existing useful and relevant functionality.

> And to quote http://dlang.org/phobos/,
>
> "No pointless wrappers around C runtime library functions or OS API
> functions. [...] Pointless D wrappers around those functions just adds
> blather, bloat, baggage and bugs."

This quote is thoroughly misapplied. A pointless wrapper is a one-liner. 
Writing a passable wrapper for exec* is quite a bit more involved.

> That said, they are not actually deprecated yet (as in marked with the
> "deprecated" attribute), so if the community wants them back, it is a
> simple matter of removing the deprecation notices.

I hope I provided compelling arguments.


Andrei

P.S. Also found this: "abstract final class environment". What happened 
to the naming conventions? Shouldn't that be capitalized?