On Fri, 07 Sep 2012 10:35:37 -0400, monarch_dodra <monarchdo...@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
