On Saturday, 8 September 2012 at 12:10:26 UTC, kenji hara wrote:
2012/9/8 monarch_dodra <[email protected]>:
[snip]
Still, I find it horrible to have to create a named "dummy"
variable just
when I simply want to pass a copy of my range.
Why you are afraid to declaring "dummy" variable?
formattedRead is a parser, not an algorithm (as I said in the
pull
request comment). After calling it, zero or more elements will
remain.
And, in almost cases, the remains will be used other purpose,
or just
checked that is empty.
int n = formattedRead(input_range, fmt, args...);
next_parsing(input_range); // reusing input_range
assert(input_range.empty); // or just checked that is empty
If formattedRead can receive rvalue, calling it would ignore the
remains, and it will cause hidden bug.
int n = formattedRead(r.save, fmt, args...);
// If the remains is not empty, it is ignored. Is this
expected, or
something logical bug?
auto dummy = r.save;
int n = formattedRead(dummy, fmt, args...);
assert(dummy.empty); // You can assert that remains should be
empty.
formattedRead returns multiple states (the values which are
read, how
many values are read, and remains of input), so allowing to
ignore
them would introduce bad usage and possibilities of bugs.
Kenji Hara
Hum, I think I see your point, although in my opinion, checking
the return value is all that is required for generic error
checking.
Checking the state of the range afterwards is being super extra
careful for a specific use case, and should not necessarilly be
forced onto the programmer.
I'll close the pull in the morning.
