On 15/04/18 09:39, Jonathan M Davis wrote:

It's extremely common for range-based functions to copy front. Even foreach
does it. e.g.

Not necessarily:

foreach(ref e; [S(0), S(1), S(2)]){}

While that would work with foreach, it will not work with anything that expects an inputRange (and since D defines a forward range as an extension, this is also not a forward range).

If non-copyable types were allowed, then no function which accepted a range
would be allowed to copy front without first checking that front was
copyable (something that most code simply isn't going to do)

No, that's not correct.

If non-copyable types were allowed, then functions that accept a range would fail to compile on non-copyable types if they do a copy.

But the flip side is that if non-copyable would be allowed, a lot of functions that current copy would not. There are far too many unnecessary copies in the code that serve no purpose, but they are invisible, so they are not fixed.

Remember also that a large percentage of ranges that don't wrap dynamic
arrays put their elements on the stack, which means that whenever the range
is copied, the elements are copied.

If I am guaranteed to be able to copy an input range, what's the difference between it and a forward range?

Strike that, I have a better one: If I am allowed to copy an input range, what does the "save" function in forward range even mean?

I'm not sure why it ends up printing each of them 3 times rather than 2,

Because some code somewhere does an unnecessary copy?

the fact that foreach copies any range that it's given means that in order
to have ranges allow non-copyable types, we'd have to change how foreach
worked, which would break a lot of code. Right now,

Like I said above, foreach(ref) works with "input ranges" that define ref return from front to uncopyable objects. Foreach without ref doesn't, but that's mandatory from the interface: You cannot iterate copies of a range returning uncopyable objects.

As for ranges that store the values inside them: you REALLY don't want to copy those around. They may get quite big (not to mention that I don't see how you can define one over a non-copyable type).

foreach(e; range)

is lowered to something like

for(auto __range = range; !__range.empty; __range.popFront())
     auto e = __range.front;

And that indeed generates a lot of confusion regarding what running two foreaches in a row does. This is a bug that already affects more than just uncopyable objects.

That requires both copying the range and copying front. We could
theoretically change it so that everywhere that e was used, it would be
replaced with __range.front

Like I said, already solved for foreach(ref)

Now, generic range-based code really shouldn't ever use a range after it's
been copied, since whether mutating the copy affects the original depends on
the implementation of the range (and thus generic code should assume that
foreach may have consumed the range and call save if it doesn't want that to
happen), but lots of code does it anyway,

And allowing ranges with uncopyable members would turn this potential deadly run-time bugs into easy to find compile time errors. Sound like a great reason to allow it, to me.

and if the code isn't generic, it
can work just fine, since then the code can depend on the semantics of that
specific range type

Such as it being copyable? Non-generic code is of no relevance to this discussion, as far as I can tell.

Also, in order for a range to work with a non-copyable type, either front
would have to return by ref or it would have to construct a new object to
return so that it could be moved rather than copied.


I expect that quite a
few ranges would have problems with such a restriction,

Then those ranges will not work with non-copyable objects. That's no reason to make it impossible for *any* range to work with non-copyable.

In addition, it's quite possible that forcing functions to not copy front
would hurt performance.

I'm going to stop responding now, because, frankly, I think you and I are having very different discussions.

You seem to be advocating against making *all* ranges support non-copyable types, while I'm merely asking that *any* range be allowed to support such types.

Current situation is that a range with uncopyable types is not considered an input range, and cannot use any phobos range functions, including some that it should be able to use without a problem.

There is no reason to block such ranges from using "map" or "any", except the fact they require that the type answer "isInputRange" with true.

IIRC, when this has come up previously, Andrei ruled that supporting
non-copyable types simply wasn't worth the extra complication, though a
quick search doesn't turn up anything where he talked about it. So, I can't
verify that at the moment.

I will trust Andrei to weigh in on this point if he thinks he should. Until he does, please feel free to only bring up points you are willing to argue yourself.


Reply via email to