Rework tokio_tcp and tokio_udp re-exports in tokio::net #548
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,54 +1,71 @@ | ||
| //! TCP/UDP/Unix bindings for `tokio`. | ||
| //! | ||
| //! This module contains the TCP/UDP/Unix networking types, similar to the standard | ||
| //! library, which can be used to implement networking protocols. | ||
|
|
||
| pub mod tcp { | ||
| //! TCP bindings for `tokio`. | ||
| //! | ||
| //! Connecting to an address, via TCP, can be done using [`TcpStream`]'s | ||
| //! [`connect`] method, which returns [`ConnectFuture`]. `ConnectFuture` | ||
| //! implements a future which returns a `TcpStream`. | ||
| //! | ||
| //! To listen on an address [`TcpListener`] can be used. `TcpListener`'s | ||
| //! [`incoming`][incoming_method] method can be used to accept new connections. | ||
| //! It return the [`Incoming`] struct, which implements a stream which returns | ||
| //! `TcpStream`s. | ||
| //! | ||
| //! [`TcpStream`]: struct.TcpStream.html | ||
| //! [`connect`]: struct.TcpStream.html#method.connect | ||
| //! [`ConnectFuture`]: struct.ConnectFuture.html | ||
| //! [`TcpListener`]: struct.TcpListener.html | ||
| //! [incoming_method]: struct.TcpListener.html#method.incoming | ||
| //! [`Incoming`]: struct.Incoming.html | ||
| pub use tokio_tcp::{ConnectFuture, Incoming, TcpListener, TcpStream}; | ||
| } | ||
| pub use self::tcp::{TcpListener, TcpStream}; | ||
|
|
||
| #[deprecated(note = "use `tokio::net::tcp::ConnectFuture` instead")] | ||
| /// Convenience re-export of [`tcp::ConnectFuture`](tcp/struct.ConnectFuture.html). Will be removed in a future release. | ||
|
There was a problem hiding this comment. I would just remove docs on deprecated items and also include a |
||
| pub type ConnectFuture = self::tcp::ConnectFuture; | ||
| #[deprecated(note = "use `tokio::net::tcp::Incoming` instead")] | ||
| /// Convenience re-export of [`tcp::Incoming`](tcp/struct.Incoming.html). Will be removed in a future release. | ||
| pub type Incoming = self::tcp::Incoming; | ||
|
|
||
| pub mod udp { | ||
| //! UDP bindings for `tokio`. | ||
| //! | ||
| //! The main struct for UDP is the [`UdpSocket`], which represents a UDP socket. | ||
| //! Reading and writing to it can be done using futures, which return the | ||
| //! [`RecvDgram`] and [`SendDgram`] structs respectively. | ||
| //! | ||
| //! For convenience it's also possible to convert raw datagrams into higher-level | ||
| //! frames. | ||
| //! | ||
| //! [`UdpSocket`]: struct.UdpSocket.html | ||
| //! [`RecvDgram`]: struct.RecvDgram.html | ||
| //! [`SendDgram`]: struct.SendDgram.html | ||
| //! [`UdpFramed`]: struct.UdpFramed.html | ||
| //! [`framed`]: struct.UdpSocket.html#method.framed | ||
| pub use tokio_udp::{RecvDgram, SendDgram, UdpFramed, UdpSocket}; | ||
| } | ||
| pub use self::udp::{UdpFramed, UdpSocket}; | ||
|
|
||
| #[deprecated(note = "use `tokio::net::udp::RecvDgram` instead")] | ||
| /// Convenience re-export of [`udp::RecvDgram`](udp/struct.RecvDgram.html). Will be removed in a future release. | ||
| pub type RecvDgram<T> = self::udp::RecvDgram<T>; | ||
| #[deprecated(note = "use `tokio::net::udp::SendDgram` instead")] | ||
| /// Convenience re-export of [`udp::SendDgram`](udp/struct.SendDgram.html). Will be removed in a future release. | ||
| pub type SendDgram<T> = self::udp::SendDgram<T>; | ||
|
|
||
| pub mod unix { | ||
|
There was a problem hiding this comment. I'm a bit torn about this, but I would suggest we stick to the current idiom of having the cfg on the entire module vs. the types inside. I think we can achieve the same level of documentation by having a There was a problem hiding this comment. Again, looks like this change was made in 7ea54a0. |
||
| //! Unix domain socket bindings for `tokio` (only available on unix systems). | ||
|
|
||
| #[cfg(unix)] | ||
| pub use tokio_uds::{ | ||
| ConnectFuture, Incoming, RecvDgram, SendDgram, UCred, UnixDatagram, UnixListener, | ||
| UnixStream, | ||
| }; | ||
| } | ||
| #[cfg(unix)] | ||
| pub use self::unix::{UnixListener, UnixStream}; | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that the current documentation should be moved into the appropriate sub module, but that leaves
tokio::netdocumentation a bit light, especially given that it is a primary module.Perhaps, you could add an "orgnaization" section, similar to https://doc.rust-lang.org/std/net/index.html.
Also, this can mention the unix module and explain that it is only available on unix platforms.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this change was made in 7ea54a0.