[Issue 18807] RefRange behaves very differently for Input Ranges and Forward Ranges

https://issues.dlang.org/show_bug.cgi?id=18807 Iain Buclaw changed: What|Removed |Added Priority|P3 |P2 --

[Issue 21087] refRange() does not work with ranges which have internal const fields

https://issues.dlang.org/show_bug.cgi?id=21087 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --

[Issue 21087] New: refRange() does not work with ranges which have internal const fields

https://issues.dlang.org/show_bug.cgi?id=21087 Issue ID: 21087 Summary: refRange() does not work with ranges which have internal const fields Product: D Version: D2 Hardware: All OS: All Status

[Issue 18657] std.range and std.algorithm can't handle refRange

||bugzi...@d-ecke.de Resolution|--- |FIXED --- Comment #8 from berni44 --- The original problem has meanwhile been fixed as well as many others related. If there are still some functions, that are not compatible with RefRange, IMHO they should be addressed

[Issue 18657] std.range and std.algorithm can't handle refRange

https://issues.dlang.org/show_bug.cgi?id=18657 --- Comment #7 from Dlang Bot --- @wilzbach created dlang/phobos pull request #6951 "Merge remote-tracking branch 'upstream/stable' into merge_stable" mentioning this issue: - make `chain` compatible with `RefRange` Part of a serie

[Issue 18657] std.range and std.algorithm can't handle refRange

https://issues.dlang.org/show_bug.cgi?id=18657 --- Comment #6 from Dlang Bot --- @MartinNowak created dlang/phobos pull request #6943 "Merge remote-tracking branch 'upstream/stable' into merge_stable" mentioning this issue: - make `chain` compatible with `RefRange` Part of a serie

[Issue 18657] std.range and std.algorithm can't handle refRange

https://issues.dlang.org/show_bug.cgi?id=18657 --- Comment #5 from Dlang Bot --- dlang/phobos pull request #6935 "make `cycle`, `splitter`, `roundRobin`, and `until` compatible with `RefRange`" was merged into stable: - 3ef957baf536b55fa9ebd93050e187f52e2c47f5 by aG0aep6G: m

[Issue 18657] std.range and std.algorithm can't handle refRange

https://issues.dlang.org/show_bug.cgi?id=18657 --- Comment #4 from Dlang Bot --- @aG0aep6G created dlang/phobos pull request #6935 "make `cycle`, `splitter`, `roundRobin`, and `until` compatible with `RefRange`" mentioning this issue: - make `cycle` compatible with `RefRang

[Issue 18657] std.range and std.algorithm can't handle refRange

https://issues.dlang.org/show_bug.cgi?id=18657 --- Comment #3 from Dlang Bot --- dlang/phobos pull request #6346 "make `group`, `chain`, and `choose` compatible with `RefRange`" was merged into stable: - b1b8b7968ffda3d64f9ee4666ebe453311eeb66e by aG0aep6G: make `chain`

[Issue 18657] std.range and std.algorithm can't handle refRange

https://issues.dlang.org/show_bug.cgi?id=18657 --- Comment #2 from Dlang Bot --- @aG0aep6G updated dlang/phobos pull request #6346 "make `group`, `chain`, and `choose` compatible with `RefRange`" mentioning this issue: - make `chain` compatible with `RefRange` Part of a series on i

[Issue 18807] RefRange behaves very differently for Input Ranges and Forward Ranges

https://issues.dlang.org/show_bug.cgi?id=18807 --- Comment #4 from Eyal <e...@weka.io> --- Indeed, and both are worth fixing. So I think it makes sense to keep these 2 issues: issue 14619 should fix compiler's foreach behavior (calling opSlice unnecessarily) this issue should fix Re

[Issue 18807] RefRange behaves very differently for Input Ranges and Forward Ranges

schvei...@yahoo.com --- Comment #3 from Steven Schveighoffer <schvei...@yahoo.com> --- There are 2 issues here. One is the same from 14619 -- the compiler is assuming opSlice on a valid range is a no-op. The second issue is that for some reason opSlice is defined in RefRange iff save is defined

[Issue 18807] RefRange behaves very differently for Input Ranges and Forward Ranges

https://issues.dlang.org/show_bug.cgi?id=18807 --- Comment #2 from Eyal <e...@weka.io> --- It's related -- but that issue is about "foreach" behavior, and this issue is about RefRange behavior, which probably should not define opSlice (as mentioned in passing in issue 14619). --

[Issue 18807] RefRange behaves very differently for Input Ranges and Forward Ranges

https://issues.dlang.org/show_bug.cgi?id=18807 ag0aep6g changed: What|Removed |Added CC||ag0ae...@gmail.com

[Issue 18807] New: RefRange behaves very differently for Input Ranges and Forward Ranges

https://issues.dlang.org/show_bug.cgi?id=18807 Issue ID: 18807 Summary: RefRange behaves very differently for Input Ranges and Forward Ranges Product: D Version: D2 Hardware: All URL: http://dlang.org

[Issue 18657] std.range and std.algorithm can't handle refRange

https://issues.dlang.org/show_bug.cgi?id=18657 Carsten Blüggel changed: What|Removed |Added CC||chi...@posteo.net --

[Issue 18657] std.range and std.algorithm can't handle refRange

https://issues.dlang.org/show_bug.cgi?id=18657 --- Comment #1 from ag0aep6g <ag0ae...@gmail.com> --- PR to fix the first three examples without touching RefRange: https://github.com/dlang/phobos/pull/6346 --

[Issue 18657] New: std.range and std.algorithm can't handle refRange

https://issues.dlang.org/show_bug.cgi?id=18657 Issue ID: 18657 Summary: std.range and std.algorithm can't handle refRange Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal

Re: RefRange behavior

On Wednesday, 14 March 2018 at 10:22:45 UTC, Alex wrote: Is there a simple workaround, maybe? ok, the workaround would be to enumerate the member and to use the former notation.

RefRange behavior

Hi all, given this: ´´´ import std.range; size_t[] arr; struct S { RefRange!(size_t[]) member; } void fun(ref size_t numByRef){} void main() { arr.length = 42; S s; s.member = refRange(); static assert(__traits(compiles, fun(s.member[0

Re: refRange with non copyable struct

On Monday, April 17, 2017 19:39:25 Stanislav Blinov via Digitalmars-d-learn wrote: > On Monday, 17 April 2017 at 19:00:44 UTC, Jonathan M Davis wrote: > > Because otherwise, it's not acting like a reference to the > > original range, which is the whole point of RefRange. The >

Re: refRange with non copyable struct

On Monday, 17 April 2017 at 19:00:44 UTC, Jonathan M Davis wrote: Because otherwise, it's not acting like a reference to the original range, which is the whole point of RefRange. The correct solution would probably be to @disable opAssign in the case where the original range can't

Re: refRange with non copyable struct

t; copyable. It might be reasonable for RefRange to be enhanced so > > that it doesn't compile in opAssign if the range isn't > > copyable, but I'd have to study RefRange in depth to know what > > the exact consequences of that would be, since it's been quite > > a

Re: refRange with non copyable struct

On Monday, 17 April 2017 at 18:07:36 UTC, Jonathan M Davis wrote: In this particular case, it looks like the main problem is RefRange's opAssign. For it to work, the type needs to be copyable. It might be reasonable for RefRange to be enhanced so that it doesn't compile in opAssign

Re: refRange with non copyable struct

On Monday, 17 April 2017 at 18:07:36 UTC, Jonathan M Davis wrote: Non-copyable types tend to wreak havoc with things - Jonathan M Davis Basicly what I use this for is to combine RAII with ranges. Which I find quite useful when doing DB queries and the data is lazily fetched since this allows

Re: refRange with non copyable struct

On Monday, April 17, 2017 17:23:32 Jerry via Digitalmars-d-learn wrote: > Hello guys, so I wanted to have a noncopyable range on the stack. > So my thoughts was to make it non copyable and use refRange > whenever I want to use it with map and others. > > But I got a compiler warnin

refRange with non copyable struct

Hello guys, so I wanted to have a noncopyable range on the stack. So my thoughts was to make it non copyable and use refRange whenever I want to use it with map and others. But I got a compiler warning when doing so like this: import std.range; void main() { NonCopyable v

[Issue 16534] RefRange should define opDollar if it defines length

https://issues.dlang.org/show_bug.cgi?id=16534 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/8dd953827c9b211c76985b48a9409c2ba0fcfd19 Fix issue 16534 - RefRange should define opDollar

[Issue 16534] RefRange should define opDollar if it defines length

https://issues.dlang.org/show_bug.cgi?id=16534 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/8dd953827c9b211c76985b48a9409c2ba0fcfd19 Fix issue 16534 - RefRange should define opDollar

[Issue 16534] RefRange should define opDollar if it defines length

https://issues.dlang.org/show_bug.cgi?id=16534 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 16534] RefRange should define opDollar if it defines length

https://issues.dlang.org/show_bug.cgi?id=16534 ZombineDev changed: What|Removed |Added Keywords||pull

[Issue 16534] RefRange should define opDollar if it defines length

https://issues.dlang.org/show_bug.cgi?id=16534 --- Comment #1 from Andrei Alexandrescu --- See also: http://forum.dlang.org/post/ns66l7$1sp5$1...@digitalmars.com --

[Issue 16534] New: RefRange should define opDollar if it defines length

https://issues.dlang.org/show_bug.cgi?id=16534 Issue ID: 16534 Summary: RefRange should define opDollar if it defines length Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal

Re: refRange and @disable this(this);

On 2016-09-14 14:39, Jerry wrote: I got a range which disables copy construction and I want to loop the range within another loop using the same range. So I thought I can mark the struct range with @disable this(this) and then use refRange to initialize the loop. So with something like

Re: refRange and @disable this(this);

bles copy construction and I want to loop the > range within another loop using the same range. > So I thought I can mark the struct range with @disable this(this) and then > use refRange to initialize the loop. > > So with something like this: > > void main() > { >

Re: refRange and @disable this(this);

On Wednesday, September 14, 2016 12:39:16 Jerry via Digitalmars-d wrote: > I got a range which disables copy construction and I want to loop > the range within another loop using the same range. > So I thought I can mark the struct range with @disable this(this) > and then

Re: refRange and @disable this(this);

On Wednesday, 14 September 2016 at 12:39:16 UTC, Jerry wrote: It feels strange that refRange ever want to copy. Bug or feature? Or more specificly, shouldn't save only be defined if the range defines it instead of using copy? Which is presume is the problem.

refRange and @disable this(this);

I got a range which disables copy construction and I want to loop the range within another loop using the same range. So I thought I can mark the struct range with @disable this(this) and then use refRange to initialize the loop. So with something like this: void main() { auto

[Issue 10885] [std.range] refRange is missing from module description tables

/f3e8844b3d0d00def99d7c9118497a0b699c6df1 Merge pull request #1522 from quickfur/issue10885 Add RefRange to ddoc overview (issue 10885) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---

[Issue 10885] [std.range] refRange is missing from module description tables

http://d.puremagic.com/issues/show_bug.cgi?id=10885 monarchdo...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Issue 10885] [std.range] refRange is missing from module description tables

http://d.puremagic.com/issues/show_bug.cgi?id=10885 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||pull CC|

[Issue 10885] New: [std.range] refRange is missing from module description tables

http://d.puremagic.com/issues/show_bug.cgi?id=10885 Summary: [std.range] refRange is missing from module description tables Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: minor

RefRange

It's a RefRange, but not completly ... Can somebody explain me that behaviour? http://dpaste.dzfl.pl/643de2a3

Re: RefRange

On 08/26/2012 08:41 AM, David wrote: It's a RefRange, but not completly ... Can somebody explain me that behaviour? http://dpaste.dzfl.pl/643de2a3 According to its documentation, RefRange works differently whether the original range is a ForwardRange or not: http://dlang.org/phobos

Re: RefRange

On Sunday, August 26, 2012 17:41:45 David wrote: It's a RefRange, but not completly ... Can somebody explain me that behaviour? http://dpaste.dzfl.pl/643de2a3 refRange simply returns the original range if it's an input range rather than a forward range, since normally, when you have an input

Re: RefRange

On Sunday, August 26, 2012 10:17:13 Jonathan M Davis wrote: On Sunday, August 26, 2012 17:41:45 David wrote: It's a RefRange, but not completly ... Can somebody explain me that behaviour? http://dpaste.dzfl.pl/643de2a3 refRange simply returns the original range if it's an input range

Re: RefRange

Am 26.08.2012 20:07, schrieb Jonathan M Davis: On Sunday, August 26, 2012 10:17:13 Jonathan M Davis wrote: On Sunday, August 26, 2012 17:41:45 David wrote: It's a RefRange, but not completly ... Can somebody explain me that behaviour? http://dpaste.dzfl.pl/643de2a3 refRange simply returns

Re: RefRange

Am 26.08.2012 18:06, schrieb Ali Çehreli: On 08/26/2012 08:41 AM, David wrote: It's a RefRange, but not completly ... Can somebody explain me that behaviour? http://dpaste.dzfl.pl/643de2a3 According to its documentation, RefRange works differently whether the original range is a ForwardRange

Re: RefRange

On 08/26/2012 02:21 PM, David wrote: I tried to implement a .save method, which uhm, just didn't work together with RefRange (isForwardRange!T succeeded, but isForwardRange!(RefRange!T) failed). What version of dmd? What is the code? When I add the following lines to the beginning of main

Re: RefRange

Am 26.08.2012 23:33, schrieb Ali Çehreli: On 08/26/2012 02:21 PM, David wrote: I tried to implement a .save method, which uhm, just didn't work together with RefRange (isForwardRange!T succeeded, but isForwardRange!(RefRange!T) failed). What version of dmd? What is the code? When I add

Re: RefRange

recognised as such by foreach. So if we could just fix foreach, and maybe add functions providing range primitives for T[]* to std.array, I don't think we need a separate RefRange. Just take the address of the range when you want to ensure it gets consumed. I don't think that that would work with save

RefRange

the function starts consuming them), but that doesn't happen for either value type ranges or arrays. Hence my wrapper type (called RefRange). The code is here: http://codepad.org/nNB4mAdN I was wondering what other people's take on it was and whether I missed something which makes it a bad idea

Re: RefRange

-based functions (assuming that save isn't called on them before the function starts consuming them), but that doesn't happen for either value type ranges or arrays. Hence my wrapper type (called RefRange). The code is here: http://codepad.org/nNB4mAdN I was wondering what other people's take

Re: RefRange

type forward ranges are automatically and unavoidably consumed by range-based functions (assuming that save isn't called on them before the function starts consuming them), but that doesn't happen for either value type ranges or arrays. Hence my wrapper type (called RefRange). The code