]> git.lizzy.rs Git - rust.git/commit
auto merge of #5398 : dbaupp/rust/core-readlines, r=graydon
authorbors <bors@rust-lang.org>
Fri, 22 Mar 2013 16:24:53 +0000 (09:24 -0700)
committerbors <bors@rust-lang.org>
Fri, 22 Mar 2013 16:24:53 +0000 (09:24 -0700)
commit1616ffd0c2627502b1015b6388480ed7429ef042
tree100e54420b065e55248161fc127d4f00f7af4767
parentd700500d0cc506f34dccdb8379cc1102becfd24f
parentf8323397aa3c7358d3c2d3fb62038768b26bfdad
auto merge of #5398 : dbaupp/rust/core-readlines, r=graydon

The `each_line` function in `ReaderUtil` acts very differently to equivalent functions in Python, Ruby, Clojure etc. E.g. given a file `t` with contents `trailing\nnew line\n` and `n` containing `no trailing\nnew line`:

Rust:
```Rust
t: ~[~"trailing", ~"new line", ~""]
n: ~[~"no trailing", ~"new line"]
```

Python:
```Python
>>> open('t').readlines()
['trailing\n', 'new line\n']
>>> open('n').readlines()
['no trailing\n', 'new line']
```

Ruby:
```Ruby
irb(main):001:0> File.readlines('t')
=> ["trailing\n", "new line\n"]
irb(main):002:0> File.readlines('n')
=> ["no trailing\n", "new line"]
```

Clojure
```Clojure
user=> (read-lines "t")
("trailing" "new line")
user=> (read-lines "n")
("no trailing" "new line")
```

The extra string that rust includes at the end is inconsistent, and means that it is impossible to distinguish between the "real" empty line a file that ends `...\n\n`, and the "fake" one after the last `\n`.

The code attached makes Rust's `each_line` act like Clojure (and PHP, i.e. not including the `\n`), as well as adjusting `str::lines` to fix the trailing empty line problem.

Also, add a convenience `read_lines` method to read all the lines in a file into a vector.
src/libcore/io.rs
src/libcore/str.rs