For anyone who isn’t familiar, the original Abstract FilePath Proposal is here: https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/abstract-file-path
In short, it tries to get rid of the
type FilePath = String mistake for various reasons.
Since it’s unlikely that this proposal will ever make it into base, the alternative proposal is this:
- write a library that implements the proposal as a new type
AbstractFilePathwith various utility functions (as opposed to replacing
unixpackage to provide
System.Posix.Files.AbstractFilePathvariants (we already have them for
Win32package to provide a similar variant
- write libraries using these types (
directoryaren’t forced to migrate)
I’ve already taken a stab at 1:
The big advantage for me personally is that there are quite a few use cases where I can get away without knowing the filename encoding. But I can only ignore the encoding if we’re dealing with untampered byte strings. In case this will move forward, I’m planning to migrate some of my libraries to this type, which are alternatives to
directory I currently use in all my projects.
The main question is basically if
Win32 would accept patches for this as new API variants. One of the reasons of AFPP is to not roundtrip through String or ByteString, so there’s not much point if we need to convert from unpinned ShortByteString before the syscall.
I think this proposal doesn’t really need complete consensus, since it’s backwards compatible and just an alternative API. It won’t change base, it won’t break existing code and it won’t force anyone to use it, if they’re not interested. And even if someone uses a library utilizing
AbstractFilePath against their will, they can still convert to String and use the other APIs.
I’m also interested to hear opinions about the current implementation. Please see the rendered documentation.
I’d also like to hear @snoyberg’s opinion, specifically, since he’s one of the authors of the original proposal.