On 12/28/14 12:04 PM, Peter Alexander wrote:
On Sunday, 28 December 2014 at 18:16:04 UTC, Andrei Alexandrescu wrote:
Very little breakage I can think of. Ranges usually don't own their
payload.
I'm thinking more about higher order ranges, e.g. take, filter, cycle,
retro; over a mutable range with ref front. Even if the underlying range
(e.g. an array) has the inout, the higher order range will need the
inout as well, so that it is propagated, no?
Not even those for the most part. The archetypal higher order range:
struct Wrapper(R)
{
private R payload;
ref ElementType!R front() {
return payload.front;
}
...
}
If R.front() returns a ref T, that's all Wrapper needs to know - the
call just works. That would be the case if e.g. R is T[].
If R.front() is inout-qualified, indeed Wrapper needs to propagate that.
In this case, however, deduction can take care of it; Walter ensures me
that deduction of inout is cheap and relatively easy. I need to add a
section on it to the DIP.
For non-templates, inout would need to be added if a range that owns its
elements is to be wrapped. But generally ranges don't own stuff (i.e.
they can disappear and stuff is still there). Containers own stuff.
Andrei
