Path as an object in std.path

[monarch_dodra]

On Thursday, 6 June 2013 at 19:29:08 UTC, Jonathan M Davis wrote:
> On Thursday, June 06, 2013 14:38:41 Andrei Alexandrescu wrote:
>> On 6/6/13 2:13 PM, Jonathan M Davis wrote:
>> >> An example of a strong justification for a redo is, for 
>> >> example,
>> >> conversion
>> >> to use ranges. std.zip needs that treatment.
>> > 
>> > Agreed.
>> 
>> Key to success for Path: somehow get it on the ranges 
>> bandwagon :o).
>
> LOL. Well, given that strings are _already_ ranges, that 
> wouldn't help it
> anywhere near as much as it does with other cases of code 
> breakage, since
> std.path is already quite range-ready.
>
> - Jonathan M Davis

Something I wanted to add:

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. This makes it easy to do certain 
otherwise hard to do operations. eg:

Change:
C:\Users\Monarch\Docs\MyFile.txt
to
D:\Users\Monarch\MyFile.txt

Regexes are fun and all, but they do come with their own 
complications, and pitfalls. And they *do* require efforts to 
write. Or use the existing interface. It works, I won't argue 
agains it, but I do find times where it is kind of clunky.

I'd be in favor of having a "Path" object, if only for being able 
to help in the construction or modification of string paths.

For example, I imagine something as:
string oldPath = `C:\Users\Monarch\Docs\MyFile.txt`:
Path   myPath  = Path(oldPath);
myPath.drive = 'D';
myPath.folders = myPath.folders[0 .. $ - 1];
string newPath = myPath.build;

I think it would be useful to have that. None of the existing 
interfaces change. It's just an optional tool that I think would 
be convenient.

--------

If I may present an analogy: C deals with "time" using the 
arithmetic "time_t" primitive. It works, is mostly convenient, 
and is the standard API. Still, C also proposes the "struct tm", 
which is a time, exploded into year/month/day/hours/min/sec.

You can do nothing with this type, except, well read and write to 
it, and convert it back to/from time_t. Yet, is has its uses, if 
only being presented in a way that might be more natural to 
manipulate. And that is reason enough for its existence.