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

[Andrei Alexandrescu]

On 10/29/13 1:25 PM, Lars T. Kyllingstad wrote:
> 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.

I think that's the weakest argument of the lot, see the rebuttal in my 
answer to it.

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

It's Posix, and Windows also implements the family. Not an argument for 
removal that Windows implements it in a suboptimal manner.

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

That's a good point. Nevertheless there are deeper reasons for that. Far 
as I can tell functions like fork() and exec() are tenuous on Windows 
due to the way it's architected, so they favor other ways to go about 
things. Then they also took the time to implement exec(). No fault 
there. Just don't make it difficult to get to it.

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

Interesting, I'll do that. But my point here remains: there is no lower 
bound in the speed I need.

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

Then we have a problem. Because I am convinced I am copiously right, and 
you failed to make any comparable argument to the contrary. To me the 
only matter to deal with is my being annoying when I know I'm right. 
(That may, in fact, be the bigger problem because I can be mightily 
annoying.)

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

I can only assume Windows made a bona fide effort to make their _exec() 
implementation 
(http://msdn.microsoft.com/en-us/library/vstudio/431x4c1w.aspx) as good 
as possible within the design of that environment. I find it very forced 
to insist on letting that go to waste and moving exec() to Posix just 
because... I honestly don't know why. There was no good argument in 
favor of going any other way but fixing the mistake of deprecation.

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

Well that's a bummer but not the focus of my ire.


Andrei