-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
proposal: io/ioutil: move Discard, NopCloser, ReadAll to io #40025
Comments
And if we moved the remaining functions to a new package, But should this happen as part of a stdlib v2? It is backwards compatible, but at the cost of a fair amount of duplication. |
The fileio suggestion is #19660 for what it's worth. |
For what it's worth, I think we can correct these three symbols without waiting for a more comprehensive stdlib v2. The remaining symbols I think we can deal with at another time. It's possible they just belong in os, instead of isolated in a side package all by themselves, except that there's already an os.TempDir. |
The reactions I see above (one comment, bunch of emoji) are all positive. Does anyone object to accepting this proposal? |
No objection from me. I can never remember what's in ioutil vs io. |
Based on the discussion above, this seems like a likely accept. (Part of the reason to do this is that then you never have to use io/ioutil when working with a non-operating-system fs.FS. io/ioutil becomes OS-only.) |
Sorry to be the naysayer here, but how should we deal with the break in backwards compatibility this move causes? The go statement in the go.mod file and go fix or go fmt or such? It seems a lot of work for what is in essence a cosmetic change. Once we have generics, we will have to rethink the whole standard library anyway. I prefer all breaking changes like this one to be made at once for the V2 standard library, then I only will have to upgrade once and not a dozen times. |
My assumption was that we would move the base symbols to package io
var Discard io.Writer = devNull(0) // maybe we could make this a const?
func NopCloser(r io.Reader) io.ReadCloser { /*...*/ }
func ReadAll(r io.Reader) ([]byte, error) { /*...*/ } package ioutil
var Discard io.Writer = io.Discard
func NopCloser(r io.Reader) io.ReadCloser { return io.NopCloser(r) }
func ReadAll(r io.Reader) ([]byte, error) { return io.ReadAll(r) } |
From the proposal:
|
I've clarified in the text above that nothing will break. Other than that comment, seems like there is no change in consensus. Accepted. |
Change https://golang.org/cl/245657 mentions this issue: |
Change https://golang.org/cl/245658 mentions this issue: |
Change https://golang.org/cl/263141 mentions this issue: |
Change https://golang.org/cl/266364 mentions this issue: |
…s TempDir) from io/ioutil io/ioutil was a poorly defined collection of helpers. Proposal #40025 moved out the generic I/O helpers to io. This CL for proposal #42026 moves the OS-specific helpers to os, making the entire io/ioutil package deprecated. For #42026. Change-Id: I018bcb2115ef2ff1bc7ca36a9247eda429af21ad Reviewed-on: https://go-review.googlesource.com/c/go/+/266364 Trust: Russ Cox <[email protected]> Trust: Emmanuel Odeke <[email protected]> Run-TryBot: Russ Cox <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Emmanuel Odeke <[email protected]>
Change https://golang.org/cl/285377 mentions this issue: |
For #40025 For #40700 For #42026 Change-Id: Ib51b5e1398c4eb811506df21e3bd56dd84bd1f7e Reviewed-on: https://go-review.googlesource.com/c/go/+/285377 Trust: Ian Lance Taylor <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
Adjust to the proposal golang/go#40025.
io/ioutil exists mainly to avoid import cycles: it can make use of packages that themselves depend on io.
The practical effect of this is that io/ioutil is mainly about convenient OS file access: ReadDir, ReadFile, TempDir, TempFile, and WriteFile. These are here because os was too low level, and io cannot import os. (For more about why
io
should not depend onos
, see “Codebase Refactoring (with help from Go)”, especially section 3.)The three functions that don't quite fit this bill are Discard, NopCloser, and ReadAll. These are general, useful I/O helpers without dependencies, at least conceptually. They don't need to be in io/ioutil.
It is confusing that nearly all reader and writer adapters—like LimitReader, MultiReader, MultiWriter, TeeReader, SectionReader—are in io, while NopCloser and Discard hide in io/ioutil. They should join the others. I think it was mostly accidental that they ended up in io/ioutil.
It is similarly confusing that the reader and writer helpers—Copy, CopyBuffer, CopyN, ReadAtLeast, ReadFull, WriteString—are all in io, while ReadAll alone hides in io/ioutil. It too should join the others.
In the case of ReadAll, there is a clearer reason why it was relegated to io/ioutil: it imports bytes for access to bytes.Buffer, and bytes imports io. But ReadAll need not use bytes.Buffer, especially now that we have
append
built in.Obviously we cannot delete these three from io/ioutil. But we can move the implementations to io and leave wrappers behind. That will be easier for new users, and it lets more packages do general I/O without a dependency on os.
Edit: To be clear, no existing code will break. The old symbols will remain behind, as wrappers of the ones in io.
The text was updated successfully, but these errors were encountered: