Proposal for std.path replacement

[Rainer Schuetze]

Looks good overall. I have a few comments and nitpicks though:

 >   basename("dir/subdir/")             -->  "subdir"
 >   directory("dir/subdir/")      -->  "dir"

Is this what everybody expects? I'm not sure, but another possibility 
would be to treat these as if "dir/subdir/." is passed. What is the 
result of directory("/") or directory("d:/")?

 >   extension("file")               -->  ""
 >   extension("file.ext")           -->  "ext"

What about "file."? I tried it on NTFS, but trailing '.' seems to always 
be cut off. Is it possible to create such a file on unix systems? If 
yes, you won't be able to recreate it from the result of basename() and 
extension().

What about network shares like "\\server\share\dir\file"? Maybe it 
should also be shown in the examples? Does the "\\server" part need 
special consideration?

Rainer

Lars T. Kyllingstad wrote:
> As mentioned in the "std.path.getName(): Screwy by design?" thread, I 
> started working on a rewrite of std.path a long time ago, but I got 
> sidetracked by other things.  The recent discussion got me working on it 
> again, and it turned out there wasn't that much left to be done.
> 
> So here it is, please comment:
> 
>     http://kyllingen.net/code/ltk/doc/path.html
>     https://github.com/kyllingstad/ltk/blob/master/ltk/path.d
> 
> Features:
> 
> - Most functions work with all string types, i.e. all permutations of 
> mutable/const/immutable(char/wchar/dchar)[].  Notable exceptions are 
> toAbsolute() and toCanonical, because they rely on std.file.getcwd() 
> which returns an immutable(char)[].
> 
> - Correct behaviour in corner cases that aren't covered by the current 
> std.path.  See the other thread for some examples, or take a look at the 
> unittests for a more complete picture.
> 
> - Saner naming scheme.  (Still not set in stone, of course.)
> 
> -Lars