[Issue 14478] isInputRange failed to recognize some ranges (page 2)

https://issues.dlang.org/show_bug.cgi?id=14478 Martin Nowak <code@dawg.eu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |code@dawg.eu --- Comment #11 from Martin Nowak <code@dawg.eu> --- > I've seen plenty of cases in code where something like > > auto value = range.front; Algorithms shouldn't needlessly copy values because it might be expensive, e.g. with big values. We should probably add an isCopyable!(ElementType!R) to the algorithms that do require this. --

April 23, 2015

[Issue 14478] isInputRange failed to recognize some ranges

Posted by Jonathan M Davis

Permalink

Jonathan M Davis

Permalink

https://issues.dlang.org/show_bug.cgi?id=14478

--- Comment #12 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
(In reply to Martin Nowak from comment #11)
> Algorithms shouldn't needlessly copy values because it might be expensive,
> e.g. with big values.
> We should probably add an isCopyable!(ElementType!R) to the algorithms that do require this.

Calling front multiple times can be just as expensive (or even more so) depending on what it does - e.g. if it calculates front, that could be more expensive than copying it, or in the case of map, it actually could be allocating a new value for every call to front. So, it's not at all cut and dry as to whether copying front is cheaper or not - especially if the value of front needs to be used multiple times before popFront gets called again.

And while I agree that we should avoid unnecessary copying, when the cost of copying has come up in the past, it's pretty much been stated that copying has to be cheap (e.g. IIRC, Andrei always insists that copying should be O(1) - even with postblits - which seems unreasonable to me). So, whether it's a good idea or not, we've generally assumed that copying elements is cheap.

The real problem though is that whether it's cheaper to call front once and copy the result or to call it multiple times without copying the result depends on what the range actually does, and there's no way to know. However, given map's behavior in particular, I'd tend to argue that we'd normally want to copy front rather than call it multiple times, which becomes problematic if we then have to worry about whether front is copyable. Some algorithms avoid the problem by only needing to access front once per element, but many of them need to access it multiple times.

--

https://issues.dlang.org/show_bug.cgi?id=14478 Lars T. Kyllingstad <bugzilla@kyllingen.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla@kyllingen.net --- Comment #13 from Lars T. Kyllingstad <bugzilla@kyllingen.net> --- I use a lot of noncopyable types, and I also think it is really important that they work with ranges. The comparison with C++ containers is somewhat tenuous, as containers generally manage their own elements and therefore need to be able to move them around. Ranges, on the other hand, typically do *not* own their elements, they are just views on someone else's. Consider this: struct S { @disable this(this); } S[9] array; auto slice = array[1 .. 5]; You would be very surprised if that last line didn't work, right? Ranges are just a higher-order abstraction of slices. Element copyability should most definitely be an orthogonal requirement to range-ness. As Peter pointed out, this will strictly be a loosening of a constraint, and as such will not break any existing code. To me it seems like a no-brainer. --

https://issues.dlang.org/show_bug.cgi?id=14478 greenify <greeenify@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |greeenify@gmail.com --

https://issues.dlang.org/show_bug.cgi?id=14478 Dlang Bot <dlang-bot@dlang.rocks> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |pull --- Comment #14 from Dlang Bot <dlang-bot@dlang.rocks> --- @RazvanN7 created dlang/phobos pull request #7188 "Fix Issue 14478 - isInputRange should allow ranges of non-copyable elements" fixing this issue: - Fix Issue 14478 - isInputRange should allow ranges of non-copyable elements https://github.com/dlang/phobos/pull/7188 --

https://issues.dlang.org/show_bug.cgi?id=14478 --- Comment #15 from Jonathan M Davis <issues.dlang@jmdavisProg.com> --- This issue has some similarities to issue #15413, but 15413 deals with ranges which are non-copyable, whereas this deals with ranges with elements which are non-copyable (though a range with non-copyable elements would also be non-copyable if the elements were contained directly in the range as occurs with some range types - e.g. std.range's only). --

https://issues.dlang.org/show_bug.cgi?id=14478 Iain Buclaw <ibuclaw@gdcproject.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P1 |P4 --

https://issues.dlang.org/show_bug.cgi?id=14478 Jan Jurzitza <d.bugs@webfreak.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |d.bugs@webfreak.org --- Comment #16 from Jan Jurzitza <d.bugs@webfreak.org> --- The linked PR changes have been merged as https://github.com/dlang/phobos/pull/8573 The issue title works now / has been fixed. `chain` still doesn't make use of this though. --

https://issues.dlang.org/show_bug.cgi?id=14478 --- Comment #17 from Dlang Bot <dlang-bot@dlang.rocks> --- @WebFreak001 created dlang/phobos pull request #8721 "fix 14478: support non-copyable elements in many range algorithms" fixing this issue: - fix 14478: support non-copyable elements in many range algorithms https://github.com/dlang/phobos/pull/8721 --

Forums