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

Closed
bcmills opened this issue Mar 22, 2017 · 6 comments
Closed

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

bcmills opened this issue Mar 22, 2017 · 6 comments
Labels
FrozenDueToAge Go2Cleanup Used by Ian and Robert for Go 2 organization. Unless you’re Ian or Robert, please do not use this. Proposal v2 A language change or incompatible library change
Milestone

Comments

@bcmills
Copy link
Contributor

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
@bradfitz bradfitz added the v2 A language change or incompatible library change label Mar 22, 2017
@ghost
Copy link

ghost commented Mar 23, 2017

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

@pwaller
Copy link
Contributor

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
@ianlancetaylor ianlancetaylor added the Go2Cleanup Used by Ian and Robert for Go 2 organization. Unless you’re Ian or Robert, please do not use this. label Jan 30, 2018
@cristaloleg
Copy link

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 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.

@changkun
Copy link
Member

Should this proposal be closed because of #42026 ?

@ianlancetaylor
Copy link
Contributor

Yes, thanks.

@golang golang locked and limited conversation to collaborators Dec 18, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge Go2Cleanup Used by Ian and Robert for Go 2 organization. Unless you’re Ian or Robert, please do not use this. Proposal v2 A language change or incompatible library change
Projects
None yet
Development

No branches or pull requests

8 participants