@Bodigrim it's still not clear to me where the types should live. If they live here, it's gonna cause problems for some packages. Any package that filepath depends on will not be able to import AbstractFilePath types.

That currently is:

        , bytestring >= 0.11.3.0
        , deepseq
        , exceptions
        , text
        , template-haskell

with the testsuite a bit more.

If we move the types somewhere else, the instances (like IsString) will either have to be orphan instances, because they require System.FilePath.Data.ByteString.Short.Decode and System.FilePath.Data.ByteString.Short.Encode, or we will have to inline those functions with the types.

@hasufell deepseq, exceptions and template-haskell do not care about AbtractFilePath much. text potentially does, but locale-dependent Data.Text.IO and friends are an antipattern any way. bytestring is more problematic, because it has decent set of file manipulations, but there is probably no work around this.

What if filepath itself provides functions similar to Data.Bytestring.{,Lazy.}{readFile,writeFile,appendFile} and Data.ByteString.Builder.writeFile, but with AbstractFilePath instead of FilePath? Relevant bytestring documentation could suggest using them instead.

What if filepath itself provides functions similar to Data.Bytestring.{,Lazy.}{readFile,writeFile,appendFile} and Data.ByteString.Builder.writeFile, but with AbstractFilePath instead of FilePath? Relevant bytestring documentation could suggest using them instead.

So far, filepath has mostly avoided having IO functions at all, except for getSearchPath.

Additionally, we cannot use base provided functions to open files, because they don't support AbstractFilePath. We'd have to depend on unix and Win32, which of course is not possible. They have to depend on us.

Essentially the question is where openFile :: AbstractFilePath -> IO Handle lives. I don't see any option other than filepath itself.

openFile and friends for abstract filepath are implemented here: https://github.com/hasufell/file-io

It is much shorter than the base versions. It uses unix and Win32. Whether the implementation is really equivalent to base, I don't know. I've done some manual testing (e.g. that lazy readFile "foo" >>= writeFile "bar" does not force and that windows doesn't keep files locked). For the file contents, all functions use ByteString.