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

[Lars T. Kyllingstad]

On Tuesday, 29 October 2013 at 19:13:28 UTC, Andrei Alexandrescu 
wrote:
> On 10/29/13 11:16 AM, Lars T. Kyllingstad wrote:
> [...]
>> 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?

Even if you don't buy my arguments, I think Vladimir's point 
about exec*() basically being POSIX specific, and nothing more 
than a hack on Windows, is an even stronger argument.

You are doing platform-specific stuff, so you should resort to 
platform-specific libraries.  Were it up to me, I'd remove them 
from std.c too, forcing users to import core.sys.posix.unistd 
instead.

> [...]
>
> On usefulness: "Objection, your honor" :o). Forwarding from one 
> process to another is an essential part of process control.

It is apparently not essential enough for it to be natively 
supported on Windows.

> Loading another one and waiting until it's done is a very 
> wasteful way to replace it. [...]

I'm not suggesting this as a solution for you, but let me just 
point out that you wouldn't have to wait until it's done.  You'd 
spawn it and exit.  On Windows this is, as Vladimir points out, 
exactly what happens when you call exec*().  On POSIX it comes at 
the cost of a fork() (which I completely agree is unacceptable in 
some situations).

> [...]
>
>> 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.

Ok, I'll give you that.

>> 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.

Nope, I don't think so. :)

That said, I know that there are completely legitimate uses for 
exec*(), and I have no doubt yours is one.  I also agree that the 
fact that the functionality is already there is an argument 
against removing it.

Therefore, I would like to suggest a compromise:  I propose we 
move the functions into an std.posix.process module.  (There is 
currently no std.posix package, but we do have std.windows, so I 
don't see why we can't add it.)


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

Seems I'm the culprit again. :)  The rationale is: It walks like 
a variable, it talks like a variable, so let's name it like a 
variable.  The semantics of "environment" are those of a global 
variable (of a noncopyable associative-array-like type), and the 
fact that it's actually a class is an implementation detail.

Btw, environment has been in std.process for ages; it was not 
part of the revamp.  (Or rather, it was a part of the revamp that 
got integrated years before the rest.)

Lars