-
Notifications
You must be signed in to change notification settings - Fork 40
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.
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
consider stronger typing for Server::listen
arguments
#70
Comments
the goals of this project are to make an easier user interface. so i dont think we'd like to push this onto our developers. however, if we implement default values for port and host (#25) i think this might be something we consider. thanks for filing! |
You're welcome! As I said on users.rust-lang, I believe a project like this can be the "gateway drug" for a whole new generation of people, just like node was. Only this time they'll learn to expect safe, native software, instead of callback-tangles (sorry, a little bit tongue-in-cheek there) I can understand that Of course, there may be other things I'm missing; I've spent considerably less time on this than you two obviously have :-) |
Even in the node example, the port is a number, not a string. |
FWIW, yes to u16 for the port. A string for the host seems like the ideal choice because hostnames: |
Cliff on URLO mentions that That's good enough for me! I'm also pondering if using |
FWIW, Unix has a concept of names for particular ports, listed in
For this reason, Unix functions like …But I've rarely seen any modern code use this, so it feels really old-fashioned, and it's probably not worth supporting in |
the Server::listen call currently takes an
&str
for both host and port. This gets fed into aformat!
call, using the a str impl of ToSocketAddr.IMHO, there is no opinion to stringly-type these parameters. Taking a
std::net::IpAddr
and a u16 does exactly the same, with stronger typing. The combination(IpAddr, u16)
even has a ToSocketAddrs-impl, so it can be directly passed into the TcpListener.As discussed on users.rust-lang, this would add some boilerplate on the user-side to create the IpAddr:
The text was updated successfully, but these errors were encountered: