Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Tracking issue for read_exact (RFC #980) #27585

Closed
aturon opened this issue Aug 7, 2015 · 9 comments · Fixed by #30187
Closed

Tracking issue for read_exact (RFC #980) #27585

aturon opened this issue Aug 7, 2015 · 9 comments · Fixed by #30187
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@aturon
Copy link
Member

aturon commented Aug 7, 2015

rust-lang/rfcs#980
@aturon aturon added A-libs B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. labels Aug 7, 2015
@aturon aturon mentioned this issue Aug 7, 2015
Merged
@cesarb cesarb mentioned this issue Aug 7, 2015
Merged
@cesarb
Copy link
Contributor

cesarb commented Aug 7, 2015

I posted the proposed implementation I wrote a few weeks ago as #27588

@alexcrichton alexcrichton added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Aug 11, 2015
bors added a commit that referenced this issue Aug 30, 2015
@bors
Auto merge of #27588 - cesarb:read_all, r=alexcrichton
4bb9023 
This implements the proposed "read_exact" RFC (rust-lang/rfcs#980).

Tracking issue: #27585
mlalic added a commit to mlalic/solicit that referenced this issue Aug 31, 2015
@mlalic
Fix name collision for read_exact on TransportStream trait
caa1e95 
The `std::io::Read` trait is about to get its own implementation of the
`read_exact` method (rust-lang/rust#27585).

This causes a name resolution problem on the nightly version since
the compiler is unable to decide which implementation of the method
should be used. This commit fixes the problem by explicitly requesting
the `TransportStream` method to be used.

Closes #13
@mkpankov
Copy link
Contributor

Any plans on stabilizing this? I'd like to use read_exact() on stable.

@sfackler
Copy link
Member

We'll be identifying features to stabilize in the next couple of weeks, and I'd be on board with this being one of them. I'll nominate it now so we don't forget.

@alexcrichton
Copy link
Member

🔔 This issue is now entering its cycle-long final comment period for stabilization 🔔

@alexcrichton alexcrichton added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed I-nominated labels Nov 5, 2015
@jonas-schievink
Copy link
Contributor

One thing that caught my eye: This can return ErrorKind::UnexpectedEOF. Shouldn't the variant be named UnexpectedEof?

@alexcrichton
Copy link
Member

Good point! I do believe it should be called UnexpectedEof as well

@cesarb
Copy link
Contributor

cesarb commented Nov 11, 2015

This can return ErrorKind::UnexpectedEOF. Shouldn't the variant be named UnexpectedEof?

Well, UnexpectedEOF is short for UnexpectedEndOfFile, so it also makes sense to have the EOF in all-uppercase. That said, the reason I called it UnexpectedEOF was solely "the byteorder crate called it UnexpectedEOF". Other than what I said in the "Naming" section of the RFC, I don't have any opinion on this matter; either UnexpectedEOF or UnexpectedEof would work equally well IMO.

@alexcrichton
Copy link
Member

Ah yeah our naming conventions, however, say:

In CamelCase, acronyms count as one word: use Uuid rather than UUID. In snake_case, acronyms are lower-cased: is_xid_start.

So along those lines it should be Eof rather than EOF

@alexcrichton
Copy link
Member

The libs team discussed this during triage today and the conclusion was to stabilize with the renaming of UnexpectedEOF to UnexpectedEof

@alexcrichton alexcrichton mentioned this issue Dec 3, 2015
Merged
alexcrichton added a commit to alexcrichton/rust that referenced this issue Dec 5, 2015
@alexcrichton
std: Stabilize APIs for the 1.6 release
464cdff 
This commit is the standard API stabilization commit for the 1.6 release cycle.
The list of issues and APIs below have all been through their cycle-long FCP and
the libs team decisions are listed below

Stabilized APIs

* `Read::read_exact`
* `ErrorKind::UnexpectedEof` (renamed from `UnexpectedEOF`)
* libcore -- this was a bit of a nuanced stabilization, the crate itself is now
  marked as `#[stable]` and the methods appearing via traits for primitives like
  `char` and `str` are now also marked as stable. Note that the extension traits
  themeselves are marked as unstable as they're imported via the prelude. The
  `try!` macro was also moved from the standard library into libcore to have the
  same interface. Otherwise the functions all have copied stability from the
  standard library now.
* The `#![no_std]` attribute
* `fs::DirBuilder`
* `fs::DirBuilder::new`
* `fs::DirBuilder::recursive`
* `fs::DirBuilder::create`
* `os::unix::fs::DirBuilderExt`
* `os::unix::fs::DirBuilderExt::mode`
* `vec::Drain`
* `vec::Vec::drain`
* `string::Drain`
* `string::String::drain`
* `vec_deque::Drain`
* `vec_deque::VecDeque::drain`
* `collections::hash_map::Drain`
* `collections::hash_map::HashMap::drain`
* `collections::hash_set::Drain`
* `collections::hash_set::HashSet::drain`
* `collections::binary_heap::Drain`
* `collections::binary_heap::BinaryHeap::drain`
* `Vec::extend_from_slice` (renamed from `push_all`)
* `Mutex::get_mut`
* `Mutex::into_inner`
* `RwLock::get_mut`
* `RwLock::into_inner`
* `Iterator::min_by_key` (renamed from `min_by`)
* `Iterator::max_by_key` (renamed from `max_by`)

Deprecated APIs

* `ErrorKind::UnexpectedEOF` (renamed to `UnexpectedEof`)
* `OsString::from_bytes`
* `OsStr::to_cstring`
* `OsStr::to_bytes`
* `fs::walk_dir` and `fs::WalkDir`
* `path::Components::peek`
* `slice::bytes::MutableByteVector`
* `slice::bytes::copy_memory`
* `Vec::push_all` (renamed to `extend_from_slice`)
* `Duration::span`
* `IpAddr`
* `SocketAddr::ip`
* `Read::tee`
* `io::Tee`
* `Write::broadcast`
* `io::Broadcast`
* `Iterator::min_by` (renamed to `min_by_key`)
* `Iterator::max_by` (renamed to `max_by_key`)
* `net::lookup_addr`

New APIs (still unstable)

* `<[T]>::sort_by_key` (added to mirror `min_by_key`)

Closes rust-lang#27585
Closes rust-lang#27704
Closes rust-lang#27707
Closes rust-lang#27710
Closes rust-lang#27711
Closes rust-lang#27727
Closes rust-lang#27740
Closes rust-lang#27744
Closes rust-lang#27799
Closes rust-lang#27801
cc rust-lang#27801 (doesn't close as `Chars` is still unstable)
Closes rust-lang#28968
bors added a commit that referenced this issue Dec 6, 2015
@bors
Auto merge of #30187 - alexcrichton:stabilize-1.6, r=aturon
c4b1638 
This commit is the standard API stabilization commit for the 1.6 release cycle.
The list of issues and APIs below have all been through their cycle-long FCP and
the libs team decisions are listed below

Stabilized APIs

* `Read::read_exact`
* `ErrorKind::UnexpectedEof` (renamed from `UnexpectedEOF`)
* libcore -- this was a bit of a nuanced stabilization, the crate itself is now
  marked as `#[stable]` and the methods appearing via traits for primitives like
  `char` and `str` are now also marked as stable. Note that the extension traits
  themeselves are marked as unstable as they're imported via the prelude. The
  `try!` macro was also moved from the standard library into libcore to have the
  same interface. Otherwise the functions all have copied stability from the
  standard library now.
* `fs::DirBuilder`
* `fs::DirBuilder::new`
* `fs::DirBuilder::recursive`
* `fs::DirBuilder::create`
* `os::unix::fs::DirBuilderExt`
* `os::unix::fs::DirBuilderExt::mode`
* `vec::Drain`
* `vec::Vec::drain`
* `string::Drain`
* `string::String::drain`
* `vec_deque::Drain`
* `vec_deque::VecDeque::drain`
* `collections::hash_map::Drain`
* `collections::hash_map::HashMap::drain`
* `collections::hash_set::Drain`
* `collections::hash_set::HashSet::drain`
* `collections::binary_heap::Drain`
* `collections::binary_heap::BinaryHeap::drain`
* `Vec::extend_from_slice` (renamed from `push_all`)
* `Mutex::get_mut`
* `Mutex::into_inner`
* `RwLock::get_mut`
* `RwLock::into_inner`
* `Iterator::min_by_key` (renamed from `min_by`)
* `Iterator::max_by_key` (renamed from `max_by`)

Deprecated APIs

* `ErrorKind::UnexpectedEOF` (renamed to `UnexpectedEof`)
* `OsString::from_bytes`
* `OsStr::to_cstring`
* `OsStr::to_bytes`
* `fs::walk_dir` and `fs::WalkDir`
* `path::Components::peek`
* `slice::bytes::MutableByteVector`
* `slice::bytes::copy_memory`
* `Vec::push_all` (renamed to `extend_from_slice`)
* `Duration::span`
* `IpAddr`
* `SocketAddr::ip`
* `Read::tee`
* `io::Tee`
* `Write::broadcast`
* `io::Broadcast`
* `Iterator::min_by` (renamed to `min_by_key`)
* `Iterator::max_by` (renamed to `max_by_key`)
* `net::lookup_addr`

New APIs (still unstable)

* `<[T]>::sort_by_key` (added to mirror `min_by_key`)

Closes #27585
Closes #27704
Closes #27707
Closes #27710
Closes #27711
Closes #27727
Closes #27740
Closes #27744
Closes #27799
Closes #27801
cc #27801 (doesn't close as `Chars` is still unstable)
Closes #28968
@steveklabnik steveklabnik mentioned this issue Dec 18, 2015
Closed
@softprops softprops mentioned this issue Dec 27, 2015
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

std: Stabilize APIs for the 1.6 release alexcrichton/rust
6 participants
@cesarb @alexcrichton @mkpankov @aturon @sfackler @jonas-schievink