Formatted read consumes input

[Steven Schveighoffer]

On Fri, 07 Sep 2012 10:35:37 -0400, monarch_dodra <monarchdodra at gmail.com>  
wrote:

> On Friday, 7 September 2012 at 13:58:43 UTC, Steven Schveighoffer wrote:
>> On Thu, 23 Aug 2012 07:33:13 -0400, monarch_dodra
>>
>> The only issue is, what if you *do* want ref behavior for strings?  You  
>> would need to wrap the string into a ref'd range.
>>  That is not a good proposition.  Unfortunately, the way IFTI works,  
>> there isn't an opportunity to affect the parameter type IFTI decides to  
>> use.
>>
>> [SNIP]
>>
>> -Steve
>
> If you want *do* ref behavior, I still don't see why you we don't just  
> do it the algorithm way of return by value:
>
> ----
> Tuple!(uint, R)
> formattedRead2(R, Char, S...)(R r, const(Char)[] fmt, S args)
> {
>      auto ret = formattedRead(r, fmt, args);
>      return Tuple!(uint, R)(ret, r);
> }
>
> void main()
> {
>    string s = "42 worlds";
>    int v;
>    s = formattedRead(s.save, "%d", &v)[1];
>    writefln("[%s][%s]", v, s);
> }
> ----
>

This looks ugly.  Returning a tuple and having to split the result is  
horrible, I hated dealing with that in C++ (and I even wrote stuff that  
returned pairs!)

Not only that, but there are possible ranges which may not be reassignable.

I'd rather have a way to wrap a string into a ref-based input range.

We have three situations:

1. input range is a ref type already (i.e. a class or a pImpl struct), no  
need to pass this by ref, just wastes cycles doing double dereference.
2. input range is a value type, and you want to preserve the original.
3. input range is a value type, and you want to update the original.

I'd like to see the library automatically make the right decision for 1,  
and give you some mechanism to choose between 2 and 3.  To preserve  
existing code, 3 should be the default.

-Steve