std.format.formattedRead: fix returned count of parsed variables

[agordon]

Hello,

I'd like to suggest the following patch for "std.format.formattedRead".
It deals with correctly counting the number of parsed variables, when the parameter passed to "formattedRead()" is a tuple.

Current behavior is confusing, and counts all the members of the tuple as 1, regardless of how many were correctly parsed. See the unittests for examples.

Regards,
-gordon

[andralex]

I'm not sure about this - as a type instantiation, a tuple counts as one object.

[monarchdodra]

Is the behavior even documented and expected to begin with? I'd have expected a single %s to be enough to initialize the tuple, as with EVERY other type. If anything, I'd argue it's bad design, as the implementation of formattedRead has internal knowledge of what a Tuple is. Such a behavior would not be duplicate-able for my user defined "Pair" type, for example :/

I'm not sure about this - as a type instantiation, a tuple counts as one object.

Yeah, but it's 3 different flags. What happens if the parse fails on the third flag? The user needs to know which spec number has failed.

But again, I'm surprised by the behavior. I think a single %s should initialize a tuple. If the user wants 3 flags, then he should use .expand (I think that works, correct?)

[monarchdodra]

I'd have expected a single %s to be enough to initialize the tuple, as with EVERY other type.

Actually, I think this comment is wrong. I think I should finalize my DIP for generic variable parsing, and "fromString" proposal.

[agordon]

Hello,

After re-reading the code for "format.d", I realized that "formattedRead()" is actually much more complicated than I expected (with some surprising side-effects, at least for me) - so it's best not to modify it for now.

Thanks,
-gordon