Re: Path as an object in std.path

[Lars T. Kyllingstad]

On Friday, 7 June 2013 at 17:27:16 UTC, Andrei Alexandrescu wrote:
On 6/7/13 1:04 PM, monarch_dodra wrote:
I think using string as the main form of representation for a 
path is fine.

However, there are times where it is convenient to be able to 
explode a
path into a structure, where each part is clearly separate 
from the
next.

Tuple!(
    string, "drive",
    string[], "folders",
    string, "basename",
    string, "extension"
)
parsePath(string path);

string buildPath(string drive, string[] folders, string 
basename, string extension);

This is a good idea.  Not only is it convenient, but as there is 
a lot of overlap in the work done by the various path 
decomposition functions, it will also improve performance when 
you need the results of several of them.

But why stop at the parts you have listed there?  Why not offer 
every possible decomposition the user could ever want?  It's 
about the same amount of work, because the number of "split 
points" you need to find is exactly the same.

Splitting the directory part into separate segments should be 
optional, since it allocates.

  DecomposedPath!(inout(C)) decompose(inout(C)[] path, bool 
splitDir = true);

  struct DecomposedPath(C) if (isSomeChar!C)
  {
      C[] driveName;      /// Equal to driveName()
      C[] dirName;        /// Equal to dirName()
      C[] noDriveDir;     /// Equal to dirName().stripDrive()
      C[] rootName;       /// Equal to rootName()
      C[] baseName;       /// Equal to baseName()
      C[] stem;           /// Equal to baseName().stripExtension()
      C[] extension;      /// Equal to extension()

      /// Equal to dirName().pathSplitter().array()  (optional)
      C[][] dirSegments;
  }