On Tuesday, 29 October 2013 at 20:44:50 UTC, Andrei Alexandrescu
wrote:
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.
I've rebutted your rebuttal in another post.
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.
Like I said in the other post, suboptimal is one thing, *wrong*
is another.
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.
I've suggested a way to make it easy to get to, but which
discourages its use on Windows: Put it in std.posix.
[...]
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.)
Good thing I'm halfway around the globe, then. :)
-Lars
