On Friday, 13 July 2012 at 09:47:26 UTC, Jonathan M Davis wrote:
On Friday, July 13, 2012 11:23:41 monarch_dodra wrote:
I think that in the case of your example, if "range" fulfills
the
requirements for (at least) an input range, then "save"
*should*
be called instead of "opSlice". I'm *think* this is what the
compiler does, but I'm not 100% sure.
The compiler never calls save. It will call opSlice on
non-ranges, but it'll
never call save on anything. It doesn't even know that save
exists. It's
unnecessary for ranges which aren't reference types, and you
already have to
worry about calling save on ranges that could be reference
types any time that
you pass them to a function that you don't want to consume it,
so it's not
really a big deal to have to call save with foreach for such
ranges. Most
range-based functions don't even use foreach much anyway.
- Jonathan M Davis
What exactly are the semantics of save? The reference in
std.range isn't very clear. It would appear it is only useful it
its *existence* that promotes a range from input to forward.
However, how is it different from a simple assignment?
Also, if you are supposed to call save before a foreach
"consumes" your range, then why does foreach even bother making a
copy of the range before iterating on it? Isn't this behavior
promoting dangerous usage for ranges where save is simply
"{return this;}", but bites you in the ass the day you use a
range with a specific save?
I'm confused...
