<pre class="notranslate">In the go.tools repo, godoc/vfs/vfs.go defines a very useful FileSystem type:

type FileSystem interface {
        Opener
        Lstat(path string) (os.FileInfo, error)
        Stat(path string) (os.FileInfo, error)
        ReadDir(path string) ([]os.FileInfo, error)
        String() string
}

type Opener interface {
        Open(name string) (ReadSeekCloser, error)
}

type ReadSeekCloser interface {
        io.Reader
        io.Seeker
        io.Closer
}

There are other useful packages in go.tools (and elsewhere on GitHub) that make use of
FileSystem interface implementations.

But the fact that ReadSeekCloser is a named type makes it impossible (as best I can
tell) to implement vfs.FileSystem in an external package without importing vfs (and thus
pulling down the whole go.tools repo). This goes against the spirit of implicit
satisfaction of interfaces.

For example, I created a package (<a href="https://sourcegraph.com/sourcegraph/go-vcs)" rel="nofollow">https://sourcegraph.com/sourcegraph/go-vcs)</a> that
implements an almost identical interface to vfs.FileSystem, but to avoid adding go.tools
as a dependency, I copied the 3 above types to my package. Now people want to use my
package's VCS FileSystem implementation with other godoc/vfs/... packages, and they
can't (see <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="45719242" data-permission-text="Title is private" data-url="https://github.com/sourcegraph/go-vcs/issues/11" data-hovercard-type="issue" data-hovercard-url="/sourcegraph/go-vcs/issues/11/hovercard" href="https://github.com/sourcegraph/go-vcs/issues/11">sourcegraph/go-vcs#11</a>.

I believe that vfs.FileSystem is an extremely useful building block, and it would make
it much easier if people could build interchangeable implementations of it without
importing go.tools. (As an aside, we use it in multiple places at Sourcegraph, and
Jeremy Saenz mentioned it on stage at dotGo as a "hidden gem".)

Would you consider any of the following solutions?

1) Changing godoc/vfs's (Opener).Open method to return
(interface{io.Reader;io.Seeker;io.Closer},error) instead of creating a separate named
ReadSeekCloser type (external packages could satisfy the interface by simply using the
anonymous interface type)
2) Adding ReadSeekCloser to the stdlib as io.ReadSeekCloser</pre>
<p dir="auto">by <strong>ibit.zee</strong>:</p>
<pre class="notranslate">go version go1.2.1 windows/386

command line is : go run _test1.go
error is : no buildable Go source files in C:\APL\!PROGRAMMING\GO

the problem is the underscore (_) in the file name, causes the file to not be found...

ZEE ;-)</pre>