diff options
| author | bors <bors@rust-lang.org> | 2014-01-09 09:31:36 -0800 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2014-01-09 09:31:36 -0800 |
| commit | 63ba93f91d6988506fd25a91c7d80820818159ab (patch) | |
| tree | 88bd8e2cb0c71065c28d15efb6711977285dee20 /src/libsyntax/ext/concat.rs | |
| parent | dd11fe17c7cf3661905c952d8233527abbff4c11 (diff) | |
| parent | a18282c3d029c9962f861c536f630eb7a307aa8e (diff) | |
| download | rust-63ba93f91d6988506fd25a91c7d80820818159ab.tar.gz rust-63ba93f91d6988506fd25a91c7d80820818159ab.zip | |
auto merge of #11376 : alexcrichton/rust/remove-eof, r=pcwalton
This is something I have been meaning to do for awhile, but upon inspection of the `eof` method on all of the `Reader` impls you may find some interesting surprises. The method returns a good answer for almost all wrapped I/O objects (buffered readers, mem readers, util readers, etc), but the actual return value on all I/O objects themselves is almost always useless. Almost no I/O object other than a file actually knows when it's hit EOF or not. I think that pretending that all objects know when they've hit the end when almost none do is probably a bad idea. I can't really come up with a good answer to "is this file descriptor at eof" or "is this tcp stream at eof" much less "is this udp socket at eof". Due to being unable to answer these questions for *all* readers, I believe that it shouldn't be a part of the core `Reader` trait.
Diffstat (limited to 'src/libsyntax/ext/concat.rs')
0 files changed, 0 insertions, 0 deletions
