std.path review: second update

[Jonathan M Davis]

On Tuesday 02 August 2011 05:41:11 Jesse Phillips wrote:
> On Mon, 01 Aug 2011 20:50:21 +0000, Jonathan M Davis wrote:
> 
> st my pragmatic, Windows-sentric view of things :)
> 
> > The problem with that is that then you _can't_ have something like
> > "foo..bar". Granted, that's not a normal thing to do, but it would be
> > problematic if it ever happened.
> 
> You can, you just wouldn't build it with these functions. And frankly if
> you are using these then you probably wouldn't want foo..bar and wouldn't
> care that it ended up foo.bar or foo..bar. You just want the proper
> extension on the proper name, which is what you'd get.
> 
> > The primary danger I see with using null for no extension and empty for
> > "." is
> > 
> > assert(extension("file.") == extension("file"));
> > 
> > That could cause problems for any program that actually runs into a file
> > which ends with a ".". Now, if Linux, Windows, and Mac OS X all prevent
> > files ending in a dot (which I seriously doubt), then it isn't really an
> > issue. Having the difference between null and empty does make it
> > possible to distinguish if you start doing stuff like
> 
> I disagree, that assertion should pass. They both have the same
> extension. If you really want to know if a file name ends in a dot,
> 
> assert("file."[$-1] == ".");
> 
> I just don't see a case where you'd be dealing with these too files and
> care to know the extension is explicitly empty or umm just empty.

The main issue that I see is that it becomes too easy to have a program think 
that the names of two files are identical if you're dealing with their pieces 
instead of their whole. Granted, this is not exactly a normal situation, but 
I'd much prefer to have it handled cleanly so that programs that get into such 
a situation don't end up being buggy rather than declaring that two items 
which aren't identical as being equal.

- Jonathan M Davis