D input: how-to (RFC)

[grauzone]

>>> int read(/+File inFile = stdin,+/ A...)(out A a) /+Uncommenting results
>>> in: Error: arithmetic/string type expected for value-parameter, not
>>> File+/
>>
>> That would make inFile a template parameter, which obviously doesn't
>> make sense with objects, and I guess File is an object. This should work:
>>
>> int read(A...)(File inFile, out A a)
> 
> OK... that works, but how would I set stdin as the default input "file"?

You can't have default arguments and variadic arguments at the same 
time. That's just how the syntax works. At best, you could change the 
signature to "int read(A...)(ref A a)". Then you could check if the 
first argument is of the type File, and if not, use a default value for 
inFile, and so on.

> I tried: int read(A...)(out A a, File inFile = stdin) but the compiler 
> hangs trying to compile it whenever I call read() using 50% of the CPU 
> resource in the process.

No matter if it's allowed or not, the compiler shouldn't hang. Maybe 
report a bug: http://d.puremagic.com/issues/

>> bools can't be read? If the implementation is incomplete, there should
>> be at least an "assert(false);", maybe even a "static assert(false);".
> 
> Got it. What value would you read for a bool though? to me it can be 
> 0||1, true||false, yes||no, etc... Would I simply use 0 && 1 and forget 
> about the rest?

Because this function seems to deal with user input, maybe you should 
allow as many as possible.

>>> else static if(is(typeof(t) == string))
>>> if(a.length > 1)
>>> a[i] = input[i];
>>> else
>>> a[i] = data;

>> Also, the array index i isn't checked for input, and random things could
>> happen. (You'd get an exception in debug mode, but not in release mode.)
> 
> ??? not sure what you mean here. i is the index of the variable as it 
> appears in the tuple "A". Why would I need to check it for input? i is 
> valid as long as we have not reached the end of the tuple.

You loop over a, so a[i] will always be correct. But input[i] could be 
out of bounds, as far as I can see.

>> Shouldn't split() already remove all white space?
> 
> split removes the white space but only from the copy of the string 
> returned. The original remains untouched.

Oops... right.