Typesafe variadics in any position

[Steven Schveighoffer]

Having a conversation about the design of the new std.process, I lamented  
that typesafe variadics must be the last element in the list of parameters.

But I would love to have a version that simply takes parameters as  
parameters.  In Tango's process class, it was a nice feature.  Stuff like  
this just worked:

setArgs("prog.exe", "arg1", "arg2");

setArgs("prog.exe arg1 arg2".split());

All with one function.

Because spawnProcess has optional parameters at the end, it makes it  
impossible to have this, since typesafe variadics requires that the  
variadic be the last part of the function parameters, and spawnProcess  
must take the optional stream and config parameters last.

But why?  This seems perfectly plausible to me:

spawnProcess(string progname, string[] args..., File _stdin = stdin, File  
_stdout = stdout, File _stderr = stderr, Config config = Config.none);

There is no ambiguity with something like:

spawnProcess("prog.exe", "arg1", "arg2", File("infile.txt"));

A string does not implicitly convert to a File, and vice versa.

Typesafe variadics are actually extremely simple to deal with (much  
simpler than C-style or D-style variadics), it's just passed as a simple D  
slice.  The compiler takes care of the nasty parts, and is entirely  
call-side.

Basically, in order for this to work, a typesafe variadic parameter must  
have no way to implicitly convert to or from the type of the next  
parameters, up to the first non-variadic parameter.

In other words:

void foo(T[] arg1..., U[] arg2..., V arg3, W[] arg4...)

This works if T, U and V cannot be implicitly converted to each other.  W  
can implicitly convert to or from V, because V is positional (there MUST  
be one V argument in this call, and that matches arg3, so any args after  
that are assumed to be arg4)

Would this work? Would it be something people want?

-Steve