http://d.puremagic.com/issues/show_bug.cgi?id=8085

           Summary: std.algorithm.joiner makes invalid assumptions about
                    front()
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: nobody@puremagic.com
        ReportedBy: bugzilla@digitalmars.com


--- Comment #0 from Walter Bright <bugzilla@digitalmars.com> 2012-05-11 12:05:54 PDT ---
Given the program:

=========================
import std.stdio;
import std.ascii;
import std.algorithm;
import std.string;

void main() {
//stdin.byChunk(1024).joiner().map!(a =>
toUpper(a)).copy(stdout.lockingTextWriter());

stdin.byLine(KeepTerminator.yes).joiner().map!(a =>
toUpper(a)).copy(stdout.lockingTextWriter());

//stdin.byLine(KeepTerminator.yes).joiner().copy(stdout.lockingTextWriter());

//stdin.byLine(KeepTerminator.yes).copy(stdout.lockingTextWriter());
}
==============================
Compile & run with:

foo <foo.d

trying one of the 4 versions. Versions 1 and 4 work, 2 and 3 fail horribly.

The output is all scrambled, like this:

IMPORT STD.ASCII;
IMPORT STD.ALGORITIMPORT STD.STRING;
M;

MPORT STD.STRING;
VVOID MAIN() {
STDIN.BYLINE(KEEPTERMINATOR.YES).JOINER().MAP!(A =>
TOUPPER(A)).COPY(STDOUT.LOCKINGTEXT //STDIN.B
YLINE(KEEPTERMINATOR.YES).JOINER().COPY(STDOUT.LOCKINGTEXTWRITER());
CKINGTEXTWRITER());
//STDIN.BYLINE(KEEPTERMINATOR.YES).COPY(STDOUT.LOCKINGTEXTWRITER());
ITER());
}
//STDIN.BYLINE(KEEPTERMINATOR.YES).COPY(STDOUT.LOCKINGTEXTWRITER());
}

Analysis from Andrei:

Go to algorithm.d line 2370, when joiner() is defined. Then go down to method
prepare(). That method calls _items.front.empty, i.e. it assumes _items.front
"works" but at the same time saves _current. At the moment _items.front is
called, _current gets overwritten.
The code should be changed to not assume that _items.front is independent from
_current.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8085


jens.k.mueller@gmx.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jens.k.mueller@gmx.de


--- Comment #1 from jens.k.mueller@gmx.de 2012-07-06 13:01:33 PDT ---
I'm thinking about fixing this issue but there are several approaches:

1. Fix joiner (BTW why name it joiner and not just join; same for splitter; Is this because there used to be a string.split or and std.path.join?)

2. Fix ByLine to not invalidate front when doing a popFront
Is it common in Phobos for a range to invalidate front? ByLine and probably
also ByChunk (haven't checked) are the only ranges that invalidate front,
aren't they. There is also ByRecord which does not show up in the
documentation.

3. If it is a common scheme to invalidate front then one could implement an adapter to store a copy of front even though that is less efficient.

I prefer option 2 because it can be implemented with little space overhead but you seem to prefer option 1 which suggests that a range *usually* invalidates front.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8085


hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx


--- Comment #2 from hsteoh@quickfur.ath.cx 2012-10-27 13:34:22 PDT ---
I think that Phobos code, where possible, should not depend on .front not being invalidated, whether or not that's a common occurrence; that way it will work correctly for more range types.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8085



--- Comment #3 from jens.k.mueller@gmx.de 2012-10-28 03:50:16 PDT ---
That is also Andrei's stand point. There was a discussion about it on the newsgroup recently. But I'm not sure that this is the consensus.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8085



--- Comment #4 from hsteoh@quickfur.ath.cx 2012-12-01 18:22:56 PST ---
https://github.com/D-Programming-Language/phobos/pull/987

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8085



--- Comment #5 from github-bugzilla@puremagic.com 2012-12-17 09:08:49 PST ---
Commit pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/baf5737beb196ba84f16440ab53a191a6958e5aa Merge pull request #987 from quickfur/new_joiner

Fix issue 8085

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8085


hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------