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.

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: rename to io/fileio or similar #19660

Open
bcmills opened this issue Mar 22, 2017 · 4 comments
Open

proposal: io/ioutil: rename to io/fileio or similar #19660

bcmills opened this issue Mar 22, 2017 · 4 comments

Comments

@bcmills
Copy link
Member

@bcmills bcmills commented Mar 22, 2017

I find myself constantly needing to look up the documentation for io and io/ioutil to figure out which package contains the thing I want to use.

The root of the problem is that ioutil isn't a coherent abstraction boundary. The suffix util doesn't add any information — if a package has no utility, it should not exist! — and the remaining information in the package name doesn't distinguish it from io. (See also the "Bad package names" section of https://blog.golang.org/package-names.)

From what I can tell, the main purpose of separating out ioutil is to reduce the dependencies of io: specifically, the dependencies on bytes, os, and sort.

In a potential Go 2, I propose to resolve those dependencies by refactoring the ioutil package as follows:

  1. Move Discard, NopCloser, and ReadAll into package io:

    • NopCloser has no dependencies.
    • Discard depends on sync, which io already depends on.
    • ReadAll uses a bytes.Buffer internally, but doesn't actually need very much of its API; it can be rewritten easily to avoid that dependency.
  2. Move ReadDir, ReadFile, TempDir, TempFile, and WriteFile to a new package, io/fileio.

    • Rename them to omit the (now-redundant) File suffix: fileio.Read instead of ioutil.ReadFile.
@gopherbot gopherbot added this to the Proposal milestone Mar 22, 2017
@gopherbot gopherbot added the Proposal label Mar 22, 2017
@bradfitz bradfitz added the Go2 label Mar 22, 2017
@opennota
Copy link

@opennota opennota commented Mar 23, 2017

io.ReadFull / ioutil.ReadAll pair is especially frustrating.

@pwaller
Copy link
Contributor

@pwaller pwaller commented Mar 23, 2017

To take the logic a bit further with respect to removing chattiness, how about (or: why not?) one step further: io/file instead of io/fileio. Then it's file.Read instead of fileio.Read. file and io together seem tautological. Especially when you throw in Read/Write, etc.

Sounding them out: file.Read, file.Write, file.Temp, file.ReadDir, file.TempDir, etc. Side thought: Maybe the latter two would read better as dir.Read and dir.Temp, if there was a io/dir package?

There may be good arguments for io/fileio instead of io/file? One that comes to mind is that people might want to call variables dir and file. Not sure if that's a much of a problem in practice or not.

@rsc rsc changed the title proposal: io/ioutil (Go 2): rename to io/fileio or similar proposal: io/ioutil: rename to io/fileio or similar Jun 16, 2017
@cristaloleg
Copy link

@cristaloleg cristaloleg commented Jul 9, 2020

One that comes to mind is that people might want to call variables dir and file. Not sure if that's a much of a problem in practice or not.

Looks like this will be a huge problem, same as net/url or path.

@cespare
Copy link
Contributor

@cespare cespare commented Jul 9, 2020

There may be good arguments for io/fileio instead of io/file? One that comes to mind is that people might want to call variables dir and file. Not sure if that's a much of a problem in practice or not.

I agree with @cristaloleg: this is absolutely a problem in practice. file and dir are incredibly common, useful variable names. To quote the Package names blog post from 5 years ago:

Don't steal good names from the user. Avoid giving a package a name that is commonly used in client code. For example, the buffered I/O package is called bufio, not buf, since buf is a good variable name for a buffer.

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

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.