Ben Rudiak-Gould
Doing a reasonable job on System.FilePath, even if it isn't perfect, will help prevent lots of applications from falling into common traps, and help make more code portable.
But the library code itself falls into the same traps! It's a great example of the kind of code we should be trying to replace!
If problems are in the implementation but the interface is right, then the module should be provided. It can be fixed later. It's a bigger problem if the design is bad.
2. It will never be possible to change the current weird behavior, because it might break legacy code.
It will be possible if the old behavior is considered a bug. I doubt that programs will make use of these bugs.
With respect to the old message you linked to: having an ADT for paths would not break any code,
I don't see an advantage of using an ADT here.
Right now each function has its own integrated parser, with slight differences in e.g. drive letter handling, and there are probably more bugs I didn't notice.
Well, they should be easy to fix as long as we precisely determine the intended semantics. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/