proposal: os/v2: File should be an interface

[robpike]

By analogy with #13473, os.File should also be an interface. That would permit a program to use files in the abstract sense, including implementations not provided by the os package.

[bradfitz]

Related: #5636 (VFS layer), in which we were never able to find a design that fit everybody's needs.

[mattn]

https://godoc.org/golang.org/x/net/webdav#FileSystem

This may be one of implementations.

[rsc]

I think I'd argue that io.File should be the interface but it's all moot now.

[bronze1man]

rsc How about follow interface?
I think following interface should work in go1.x

type FileV2 interface{
   io.ReadWriteCloser
   //....
}
func NewFileFromV2(v2 FileV2) *File{
  //...
}

[minux]

No. Please see my reply to a similar suggestion in #13473. Having version numbers in APIs is really ugly.

[rsc]

This is a long-term issue that we are not actively working on.

[bcmills]

After several years of maintaining various Google filesystem implementations, I disagree strenuously with this proposal.

Go interfaces act as bounds on types. On function inputs, they are lower bounds: every implementation must provide at least the methods described in the interface. On function outputs, they are upper bounds: even if the implementation provides methods beyond those in the interface, they are not visible in the compile-time type system, and they are therefore also less visible in the documentation.

Because they act as bounds, interfaces work best on the consumer side of an API: for example, io.Reader belongs in the package that defines io.Copy, because Copy consumes the output of a passed‐in Reader. On the other hand, interfaces do not belong on the implementation side of the API: bytes.NewReader returns a *bytes.Reader, not an io.Reader, because a *bytes.Reader provides methods that are not required of every io.Reader.

Turning that observation back toward the os package, we see that the os package is clearly on the implementation side of os.File: there are several functions in the package that return a *File, but zero that accept one as an argument other than a method receiver (#13473 notwithstanding).

If we were to make os.File an interface, that would make every further addition to the os.File API either a breaking change (because existing implementations would no longer match the new method) or a second-class, under-documented feature (because the new method would not be in the method set of the exported interface). That is a high cost.

In exchange for that cost, we would get very little benefit. It is already possible today for any package to define and use an interface with an arbitrary subset of the methods provided by *os.File, and so it is already possible for programs to use “files in the abstract sense”, independent of the os package but including *os.File.

[aviau]

interfaces work best on the consumer side of an API

Would you agree with adding symbols to ioutil so that we can pass it filesystem implementations?

Whoever writes a file system implementation is now forced to duplicate ioutil functions.