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

Lars T. Kyllingstad public at kyllingen.net
Tue Oct 29 11:16:29 PDT 2013


On Tuesday, 29 October 2013 at 03:44:37 UTC, Andrei Alexandrescu 
wrote:
> I am using the new std.process and am disappointed with it.
>
> There is no convenient function to replace the running process 
> with a new one. There used to be the exec() family of 
> functions, which conveniently use string[] for arguments etc., 
> but now the doc says:
>
> ============
> These functions are scheduled for deprecation. Please use 
> spawnShell instead (or, alternatively, the homonymous C 
> functions declared in std.c.process.)
> ============
>
> The problems are:
>
> 1. spawnShell does NOT do the same thing as exec*. The former 
> waits for the spawned process and then continues the calling 
> process. The latter _replaces_ the running process with the new 
> process.
>
> 2. The homonym (not homonymous btw) functions in std.c.process 
> use in char*, not string, which makes them unpleasant to use.
>
> So... what to do here?

Since I was the one who added the deprecation notices, I guess 
I'll have to answer for it. :)

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.

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.

To me, these functions simply fall on the wrong side of the 
usefulness/bloat line.  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."

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.

-Lars


More information about the Digitalmars-d mailing list