https://issues.dlang.org/show_bug.cgi?id=15293
--- Comment #12 from [email protected] --- (In reply to Steven Schveighoffer from comment #9) > The reason it was done this way is to allow for a common usage of readln > (namely, reading into a buffer over and over again) to continue to have good > performance. I understand that, and I think that goal is not compatible with having sane behavior. In my opinion, calling assumeSafeAppend on a smaller slice is not acceptable when larger slices may exist in the outside world. > If we took the "safe" route (and believe me, it was debated and > considered), then this code would reallocate every time a larger line was > read. When it was originally written, this is what byLine did, but now it's > changed. > > > The other readlnImpl variants don't work like that > > looking at it now, the other variants do exactly as I said above -- they > reallocate when the line is longer. Which is simply the right thing to do. With the API of readln I think we just have to accept the allocations. > So technically we could move to this, we just have to accept a drop in > performance for the code. > > Have you tested the performance of your new code vs. the current > implementation? No. I'm sure there is going to be a performance drop. I don't think that it matters, though. Correctness beats speed. It also only affects naive readln calls on Windows. byLine is already cautious about what exactly it gives readln as a buffer, so it shouldn't get slower. And on other OSs readnl already does the excessive allocations. --
