std.path review: second update

[Jonathan M Davis]

On Monday 01 August 2011 22:55:02 Jonathan M Davis wrote:
> 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.

Actually, I suppose that I could sum up my take on it by saying that if the 
two aren't absolutely identical, they shouldn't be treated as equal.

"file." and "file" do _not_ have the same extension. One has an empty extension 
whereas the other has none. Most stuff won't care about the difference, in which 
case it probably won't care whether extension("file.") == extension("file") or 
not (in fact, all it probably care about is whether the extension is a 
particular extension or not). But stuff which _does_ care about the difference 
_will_ care whether extension("file.") == extension("file"). It _won't_ want 
them to be equal.

In general, I don't like the idea of null and empty being conflated - they're 
two separate things. It's bad enough that arrays act that way in D. There's no 
need to propagate it to file extensions as well.

- Jonathan M Davis