Fix BufRead::read_line unconventional behaviour

[bdejean]

Hello,

I've read the documentation so I understand that read_line appends into the passed &mut String argument. I don't understand the use case of that behaviour. To circumvent it, one has to write its own little helper function or not forget to .clear() or .truncate(0) before each new call. So read_line's name doesn't match is behaviour because it reads and appends.

I also looked at the tests 1 and 2 for read_line and they don't even verify that append feature because they .truncate(0) between each check.

Would it be possible to deprecate that behaviour ? If not, would it be possible to document the design intent with a sensible use case, add tests for it and think about an additional simpler interface to load a line into a String ?

Thank you.

[shepmaster]

One technique can be built on top of the other, but not the other way around:

1. You can call clear and then append via read_line, implementing your overwriting method.
2. You cannot ever append to a buffer if read_line always implicitly clears the buffer.

So read_line's name doesn't match is behaviour because it reads and appends.

Following that logic, your proposed modification still wouldn't match behavior as it would read and replace.

Would it be possible to deprecate that behaviour

Doubtful.

possible to document the design intent with a sensible use case

I don't see why not. Hopefully this issue will collect more examples than mine, and you can submit a PR improving the documentation.

add tests for it

Sure, submit a PR!

think about an additional simpler interface to load a line into a String

There's nothing stopping you from doing this right now in your own code. You can write an extension trait that does what you want. It also might already exist on crates.io.