Consider making Reader::lines() reuse one buffer in place

[pcwalton]

It doesn't make a lot of sense to keep allocating over and over if the app isn't going to hold onto the strings. It hurt our perf vs. Go in https://gist.github.com/alco/5d18c046094d0abb3f58#file-timings

If the user wants new strings he or she can just convert the &str returned into a String.

cc @alexcrichton

[bluss]

This needs some new thinking -- it cannot be a simple Iterator<&str>, because all of an iterator's elements need to be independently and simultaneously valid. Simplest example, take the first two elements and compare them. Maybe there is a type of iterator element that can make it work.

Here is an example of a faux iterator using a single buffer. It uses improper .next() so that you can use it with a for loop. http://is.gd/nD6NoV

[pcwalton]

D takes this approach: http://dlang.org/phobos/std_stdio.html#.File.byLine

[alexcrichton]

Seems a little silly to optimize for microbenchmarks like this. I don't want to compromise on ergonomics just to make one benchmark here or there look at little better.

That being said, I don't really mind either way what it yields. Yielding &str is fine by me, I just want to take all these microbenchmarks with a grain of salt.

[pnkfelix]

Assigning P-low, not 1.0 milestone, under the reasoning that this is better resolved via stabilty attributes on the methods of our stdlib.

[bluss]

@alexcrichton There is no realistic way to yield &str

[alexcrichton]

This was handled in the new I/O reform and the new BufRead trait.