http://d.puremagic.com/issues/show_bug.cgi?id=8061
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #
http://d.puremagic.com/issues/show_bug.cgi?id=8061
--- Comment #12 from hst...@quickfur.ath.cx 2012-12-24 13:52:10 PST ---
Verified fixed in git head phobos 03a6e295fadd7c563a60069be0be3ada1c234666
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are re
http://d.puremagic.com/issues/show_bug.cgi?id=8061
hst...@quickfur.ath.cx changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://d.puremagic.com/issues/show_bug.cgi?id=8061
--- Comment #11 from github-bugzi...@puremagic.com 2012-12-23 18:23:22 PST ---
Commits pushed to master at https://github.com/D-Programming-Language/phobos
https://github.com/D-Programming-Language/phobos/commit/7ff2fcec063790184aac1d3aa08a0911
http://d.puremagic.com/issues/show_bug.cgi?id=8061
--- Comment #10 from hst...@quickfur.ath.cx 2012-12-20 10:07:42 PST ---
https://github.com/D-Programming-Language/phobos/pull/1019
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mai
http://d.puremagic.com/issues/show_bug.cgi?id=8061
--- Comment #9 from hst...@quickfur.ath.cx 2012-12-20 09:44:44 PST ---
In the case of [Front]Transversal, you're right, we only iterate across the
fronts of the elements in the range, so we never pop those elements ourselves.
So I guess it's OK.
http://d.puremagic.com/issues/show_bug.cgi?id=8061
monarchdo...@gmail.com changed:
What|Removed |Added
CC||monarchdo...@gmail.com
--- Com
http://d.puremagic.com/issues/show_bug.cgi?id=8061
--- Comment #7 from William Moore 2012-12-20 08:52:32 PST
---
The core of this issue is that "auto a = b;" is *SOMETIMES* equivalent to "auto
a = b.save;". This is what made me run away from ranges screaming. Assignment
can mean two entirely
http://d.puremagic.com/issues/show_bug.cgi?id=8061
--- Comment #6 from hst...@quickfur.ath.cx 2012-12-20 08:07:24 PST ---
Correction: Andrei said on the forum that the definition of .save does not
guarantee that inner ranges are saved. So std.array.save is correct. The
problem is with std.algori
http://d.puremagic.com/issues/show_bug.cgi?id=8061
--- Comment #5 from hst...@quickfur.ath.cx 2012-12-19 22:34:41 PST ---
Found cause of problem: in std.format.formatRange(), there's a static if block
that reads:
... else static if (isForwardRange!T && !isInfinite!T)
auto len = walkLength(v
http://d.puremagic.com/issues/show_bug.cgi?id=8061
hst...@quickfur.ath.cx changed:
What|Removed |Added
CC||hst...@quickfur.ath.cx
--- Com
http://d.puremagic.com/issues/show_bug.cgi?id=8061
--- Comment #4 from hst...@quickfur.ath.cx 2012-10-10 09:17:06 PDT ---
By "inner ranges will be invalidated" I meant, "inner ranges will be consumed",
so the .save'd copy of the range isn't actually a saved position in the
original range.
--
C
http://d.puremagic.com/issues/show_bug.cgi?id=8061
Jonathan M Davis changed:
What|Removed |Added
CC||jmdavisp...@gmx.com
--- Comment #2
http://d.puremagic.com/issues/show_bug.cgi?id=8061
--- Comment #1 from William Moore 2012-05-08 14:44:42 PDT
---
This appears to be a result of the inner ranges not being .saved properly when
the joiner is .saved, the outer range is an array, and the inner ranges are not
pass-by-value types.
14 matches
Mail list logo