On Tue, Feb 26, 2013 at 03:29:51PM -0500, Steven Schveighoffer wrote:
> 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 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);
[...]
> 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?
[...]
+1, yes!!!
This would also make it possible to do things like user-defined library
types that throw exception at the caller by using __FILE__ and __LINE__,
when the function is variadic. Currently, there is no way to do this:
void func(MyType args..., string file=__FILE__, size_t
line=__LINE__)
{
dotDotDotMagic(args);
if (failed)
throw new Exception(file, line, epicFailMsg);
}
Well, you could put file and line as compile-time parameters, but then
you'll get extreme template bloat.
Nor, for that matter, this:
void func(T...)(string file=__FILE__, size_t line=__LINE__,
MyType target, T args) { ... }
Which, ideally, would do the right thing when invoked like this:
MyType obj1, obj2;
func(obj2, 1, 2, 3, 'a', 'c', "c");
func(obj2, "abc", 'd', 'e', 'f', 123);
In both cases there is no ambiguity, because MyType does not implicitly
convert to string or size_t, so, in theory, the compiler should be able
to figure out what the user intended.
T
--
MAS = Mana Ada Sistem?
