On Sunday, 15 April 2018 at 10:39:32 UTC, Jonathan M Davis wrote:
On Sunday, April 15, 2018 10:14:20 Dmitry Olshansky via
Digitalmars-d wrote:
On Sunday, 15 April 2018 at 06:39:43 UTC, Jonathan M Davis
wrote:
> On Sunday, April 15, 2018 07:26:54 Shachar Shemesh via
>
> Digitalmars-d wrote:
>> [...]
>
> It's extremely common for range-based functions to copy
> front. Even foreach does it. e.g.
>
> [...]
Arguably it should “move” them.
This would have worked if input ranges didn’t have to cache
front to support multiple ‘front’ calls before popFront. Which
is a painful misfeature really as all algorithms would
optimize for touching front once anyway.
Input range should “produce” elements not keep cache of them,
forward ranges may cache current item alright.
If that were the route that we were going to go, then front and
popFront wouldn't make any sense at all. Rather, you'd treat it
more like in iterator in Java and have next() return the next
element and pop it off at the same time.
Surprisingly, they might have got that right.
But even if we did that, it wouldn't have been appropriate in
the general case to move the element unless we put serious
restrictions on what could be an input range (e.g. that would
make no sense whatsoever with dynamic arrays or any kind of
container).
There it would copy. You get rvalue either way. Another option is
ref scope T. I do not see incompatibility you seem to imply.
So, while I'd love to have the opportunity to sit down and
redesign the range API, I don't see how we really can - not and
actually have it implemented as part of the language or Phobos
anyway.
Yeah, I think as surely as we can redesign postblit. Let’s not
focus on learned helplessnes and “it’s just the way things are”.
Recent opMove shows there is great flexibility in what can be
done.
Seriously, it’s just fixing a library design issue even if its
use proved viral.
- Jonathan M Davis
