On Friday, 24 August 2012 at 13:08:43 UTC, Denis Shelomovskij
wrote:
24.08.2012 16:16, monarch_dodra пишет:
On Friday, 24 August 2012 at 11:18:55 UTC, Dmitry Olshansky
wrote:
On Thursday, 23 August 2012 at 11:33:19 UTC, monarch_dodra
wrote:
I've traced the root issue to formattedRead's signature,
which is:
uint formattedRead(R, Char, S...)(ref R r, const(Char)[]
fmt, S args);
As I explained above the reason is because the only sane
logic of
multiple reads is to consume input and to do so it needs ref.
I had actually considered that argument. But a lot of
algorithms have
the same approach, yet they don't take refs, they *return* the
consumed
front:
----
R formattedRead(R, Char, S...)(R r, const(Char)[] fmt, S args)
auto s2 = formatedRead(s, "%d", &v);
----
Or arguably:
----
Tuple!(size_t, R) formattedRead(R, Char, S...)(R r,
const(Char)[] fmt, S
args)
----
"minCount", "boyerMooreFinder" and
"levenshteinDistanceAndPath" all take
this approach to return a consumed range plus an index/count.
It's because `formattedRead` is designed to work with an input
range which isn't a forward range (not save-able).
You had me ready to throw in the towel on that argument, but
thinking harder about it, that doesn't really change anything
actually:
At the end of formattedRead, the passed range has a certain
state. whether you give this range back to the caller via "pass
by ref" or "return by value" has nothing to do with save-ability.
