Skip to content

std::io should re-export more sub-items #11119

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

Closed
alexcrichton opened this issue Dec 22, 2013 · 5 comments
Closed

std::io should re-export more sub-items #11119

alexcrichton opened this issue Dec 22, 2013 · 5 comments
Milestone

Comments

@alexcrichton
Copy link
Member

It's a little annoying to import buffered::BufferedReader and mem::MemWriter. It'd be really nice if the imports were std::io::BufferedReader and std::io::MemWriter.

If possible, I would also like to make both the mem/buffered and whatever other modules are re-exported private.

@alexcrichton
Copy link
Member Author

Nominating, if we decide to make submodules private this is a backwards-compatibility issue.

@sfackler
Copy link
Member

If the standard library is going to lean more heavily on reexports, it'd be nice to figure out some way of better presenting the documentation for the reexported items. Currently, I think it ends up living in the module it was defined in, even if that module isn't reachable. This ends up being confusing since you see documentation at a path that you can't import.

@pnkfelix
Copy link
Member

pnkfelix commented Jan 9, 2014

Accepted for 1.0, P-backcompat-libs.

bors added a commit that referenced this issue Jan 17, 2014
* Reexport io::mem and io::buffered structs directly under io, make mem/buffered
  private modules
* Remove with_mem_writer
* Remove DEFAULT_CAPACITY and use DEFAULT_BUF_SIZE (in io::buffered)

cc #11119
@brson
Copy link
Contributor

brson commented Apr 15, 2014

We're exporting a lot now. What's left?

@alexcrichton
Copy link
Member Author

Many of the utilities are currently being reexported, but very few of the I/O primitives other than File are being exported. I would expect io::TcpStream and io::UpdSocket to both be types at the top-level, along with other I/O primitives in networking and such.

This issue is becoming quite vague, however, so I think that I'm going to close this in favor of more specific issues targeting the modules that I still have in mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants