On Friday, 27 November 2015 at 08:53:26 UTC, Joseph Rushton
Wakeling wrote:
On Thursday, 26 November 2015 at 17:23:07 UTC, Andrei
Alexandrescu wrote:
So initially I thought a simple solution would be this:
struct MyForwardRange
{
enum bool isForward = true;
... empty, front, popFront ...
}
enum isForwardRange(R) =
is(typeof(R.isForward)) && R.isForward;
Then there's no need for .save(), and isForward!R can be used
for constraints etc. Reference forward ranges are not
supported but then that's liberating (fewer complications),
rare, and easy to work around by wrapping.
By "reference forward range" do you mean a reference type (per
se) or any range that contains an internal reference type (e.g.
a range whose private data includes a dynamic array)?
Obviously, Andrei will have to answer to know what he meant, but
with regards to ranges, I would consider a reference type to be
one where in
auto copy = range;
doing anything to copy or range does the exact same thing to the
other, because they refer to the exact same state. Something like
save is required to get a separate range where popping elements
from one will not affect the other.
Contrast that with a value type where copy and range are
completely separate. And then there are ranges where the copy
shares _some_ state with the original but not all, which as far
as save goes is pretty much the same as a reference type but
means that you can't rely on mutating one having the same effect
on the other one either (the easiest example would be a range
that would otherwise be a reference type but caches front).
Based on that view of things, dynamic arrays definitely are value
types. Obviously, if you start doing stuff that would mutate
their elements, then they aren't really value types, but if all
you're doing is iterating over them, then they're essentially
value types.
What we lose without save (or something else to replace it) is
the ability to have any range types that aren't value types (or
which essentially behave like them). So, a range which is a
dynamic array or a simple wrapper around a dynamic array is fine,
because copying the range is enough, but anything where a copy is
not the same as save would have been will no longer work. Using
postblit constructors like Sonke suggested solves _some_ of that
problem, but not all of it, since that doesn't work with classes,
and const doesn't work with postblit constructors, whereas we
could make it work with save. The loss of classes poses the
problem that non-templated functions can't really be made to work
with ranges. And the loss of reference type ranges in general
definitely is a problem for some uses cases.
But the more I look at the semantics involved, the more inclined
I am to argue that trying to have the same code work for both
value types and reference types is questionable at best. On top
of that, pure input ranges almost need to be reference types
(though they can currently work as pseudo-reference types at
least some of the time), and forward ranges really need to be
value types (at least as much as dynamic arrays are anyway) if we
don't want to have to call save everywhere.
I'm starting to think that it would be better to have pure input
ranges have to be reference types and forward ranges have to be
value types and then be very careful about which functions work
with both rather than simply treating all forward ranges like
pure input ranges that can also be copied via save.
- Jonathan M Davis
- range.save Freddy via Digitalmars-d
- Re: range.save Rikki Cattermole via Digitalmars-d
- Re: range.save Sönke Ludwig via Digitalmars-d
- Re: range.save Andrei Alexandrescu via Digitalmars-d
- Re: range.save Sönke Ludwig via Digitalmars-d
- Re: range.save Jonathan M Davis via Digitalmars-d
- Re: range.save Andrei Alexandrescu via Digitalmars-d
- Re: range.... Jonathan M Davis via Digitalmars-d
- Re: range.... Joseph Rushton Wakeling via Digitalmars-d
- Re: ra... Jonathan M Davis via Digitalmars-d
- Re... Joseph Rushton Wakeling via Digitalmars-d
- Re... Jonathan M Davis via Digitalmars-d
- Re... Jonathan M Davis via Digitalmars-d
- Re... Joseph Rushton Wakeling via Digitalmars-d
- Re... Jonathan M Davis via Digitalmars-d
- Re... Joseph Rushton Wakeling via Digitalmars-d
- Re... Jonathan M Davis via Digitalmars-d
- Re... Joseph Rushton Wakeling via Digitalmars-d
- Re... Joseph Rushton Wakeling via Digitalmars-d
- Re: range.save Freddy via Digitalmars-d