On Thu, 28 Sep 2017 13:56:49 -0700, alex.jakime...@gmail.com wrote: > I'm shocked to see \r\n→\n translation being defended without any > reasoning.
Well, it's just a pretty common thing to do. Perl did it for ages. And IIRC we already had tickets on this because Proc::Async didn't do it. > Why are we doing it at all? So you could write code that works the same on Window and Linux. > “\r\n => \n transformation is done consistently” consistently what? Proc::Async, IO::Handle, Str.encode, and custom decoders do this consistently. The code the OP mentions just does it in IO::Path because it's a fastpath and the `:translate-nl` option is (probably?) not fully exposed to users yet. > Basically, slurp is changing \r\n to \n. This may seem like a > reasonable thing, except that then it has to also change \r to \n. AFAIK we don't support any platform that uses `\r` as line separator character. I don't know why Str.lines cuts on lone `\r` > Long story short, .lines is already splitting the text using all > possible variants of a newline. There's no need to mangle the data in > slurp. This isn't about making input `.lines` friendly tho.
