Path as an object in std.path

[Dylan Knutson]

> I don't have a strong opinion regarding Path object vs. string 
> functions, and I agree both have advantages and disadvantages. 
> But I would be opposed to having both.

Personally, I'd prefer to just use the Path struct in std.path. 
While a Path can be represented as a string, it's not the same 
concept (the same way that a DateTime can be represented as an 
integer, but we don't just pass times around as raw integer 
types).

However, I can't imagine that'd be feasible as it'd break a lot 
of code. My suggestion would be to just keep the freestanding 
functions to operate on raw strings, and then migrate over code 
that depends on std.path to use the Path struct as needed. I 
realize that this is easier said than done, but even then it 
shouldn't be a lot of work as Path can implicitly be converted to 
a string.

This makes its integration into existing codebases/Phobos 
literally as easy as using "Path my_path = `foo\bar`" instead of 
"string my_path = `foo\bar`". You lose no functionality but gain 
type safety if you have to do any future refactoring.

>  I wouldn't like to create an "object" just to call isAbsolute.

Agreed. The best course of action would probably be keep the raw 
functions as they exist (think of them as the static versions of 
Path methods). However, for large applications, the type safety 
of a Path object makes working with paths much easier.