[phobos] next release (meaning of path)

[Jonathan M Davis]

On Monday 03 January 2011 07:43:27 Andrei Alexandrescu wrote:
> On 1/3/11 6:42 AM, Steve Schveighoffer wrote:
> > Would it be enough to have a function that takes a string (or
> > inout(char)[] if possible) and returns a string[] with the path
> > elements?  Also, a function to do the reverse.
> 
> Problem is I've seldom been in a situation in life where I could find
> use for such a function. Most of the time I want basename, dirname, and
> if applicable drive. I don't want to dissect the entire dirname.

When manipulating a file hierarchy, I have found it useful to have the path as a 
list of directories or something similar. However, most programs don't do that 
sort of thing. All they usually care about is handling a particular file. And 
that usually amounts to simply opening it for reading or writing and then 
closing it. Most programs are worried about files, not paths. The ones which 
_are_ worried about manipulating paths then find it useful to have fancier 
constructs to work with, but most programs don't need that sort of thing.

Much as I have found path types to be useful at times, they can definitely be a 
bit burdensome for simple operations, and simple operations are all that the 
vast majority of the programs out there really care about. So, I'm tempted to 
say that a path type just isn't worth the bother in std.path and leave it to a 
third party library for those who really care. But perhaps someone will be able 
to come up with a solid argument in favor of a specialized path type. I know 
that there are D users who definitely want one. I don't know if there are very 
many such folks though.

- Jonathan M Davis