fix issue 11431 - std.file.slurp fails with Windows newlines

[ghost]

No description provided.

[dlang-bot]

Thanks for your pull request and interest in making D better, @bbasile! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the annotated coverage diff directly on GitHub with CodeCov's browser extension
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	11431	normal	std.file.slurp fails with Windows newlines

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + phobos#6680"

[CyberShadow]

['\r'] doesn't compile in @nogc. Maybe just use "\r"?

[ghost]

Yes, fortunately the right overload exists.

[CyberShadow]

This looks like a pragmatic approach in line with readText/splitLines. A more pedantically correct one would be, considering that the root of the problem is byLine's default separator argument being '\n', to allow specifying a separator to pass to byLine.

One potential point of concern is breaking code which worked around the previous behavior. I.e., this code currently works but will fail with this patch:

write(deleteme, "10\r\n20\r\n");
assert(slurp!int(deleteme, "%d ") == [10, 20]);

(Note the space after %d.)

What do you think about changing line 5109 instead, from enforce(line.empty, to enforce(line.stripRight("\r").empty,?