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 _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
