Formatted read consumes input

[monarch_dodra]

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.