Hi, As maintainer, it's kind of a grey area if I need to make proposals for the filepath library, but since I'm a relatively new active maintainer for a Core library, I thought I'd err on the side of caution. Please yell if you think these are a bad idea, otherwise I'll just do them (probably over the next few weeks). * Change 1: Add -<.> as an alias for replaceExtension with the same precedence as <.> This change has been in Shake for a while now, and seems generally useful. It isn't an operator in the lens library, and it reads nicely as a combination of - (remove something) and <.> (addExtension). The argument order of replaceExtension is a bit unfortunately, since replace functions usually have the thing to replace with first, but since extensions are at the end of the FilePaths that suggests making it the second argument (which is what filepath does). In contrast, -<.> has a very obvious argument order. * Change 2: Stop testing as part of GHC The test suite is complicated enough, since it generates code from the doc comments. Having the test suite also run by GHC complicates things further, since it has to integrate with the GHC test suite environment with extra Makefiles etc. Since August 2011 the FilePath test suite actually passes even if you break the properties (oops!) so it's provided no value at all in the last 3 years. In general, running all the tests in all the places is a good thing. But I think filepath is a bit different given it's exclusively cross-platform string manipulations, so I don't think its runtime behaviour is version/platform sensitive in any way. I also develop on Windows with 4 versions of GHC, and Travis tests it on Linux with 6 versions of GHC. That seems sufficient test coverage. * Change 3: Check in the generated test code If you check out the filepath repo it won't build - you have to run some code to generate the tests first. That's a barrier to entry, and makes testing with GHC harder. I'm increasingly starting to believe that for a small number of small files where the generator ships with the code, it's easier to check in the generated code and then have Travis run the generator and check nothing changes. It's easier to get started, easier to debug when things change, and the only real cost is a few extra checkins. Thanks, Neil