Let me add some more to this. To justify the addition of such
a type, it needs to pull its own weight. For added value, it
could do one or both of the following:
1. Maintain an isValidPath() invariant, for early error
detection. (On POSIX, this is rather trivial, as any string
that does not contain a null character is in principle a valid
path, but on Windows, the situation is different.)
That's a possibility.
2. Add in-place versions of path modifiers (setExtension,
setDrive, etc.), for improved performance.
I don't think that there'll be any performance improvements by
making in place modification functions. Considering under the
hood the path object is just a string, and that string's
reference needs to be changed with each modification, I don't see
how manipulation can be made faster.
One solution would be for Path to be a trivial string wrapper
which does (1) and not (2). In this case, it is justified to
have Path *in addition to* the existing functions.
Another solution would be for Path to do (2), possibly in
addition to (1). However, in this case it should be a
*replacement* for the existing functions, and not an addition.
Otherwise, we have two almost-equal ways of doing the same
thing, which should be avoided. (I am not advocating this,
however, as it will massively break user code all over again.)
The more I think about it, the more partial I am to removing the
existing string methods in std.path. At most, using a Path object
increases number of characters typed by 6 (`Path()`). And even
then, chances are you'll be saving characters as method names can
be simplified to remove `path` from them: buildNormalizedPath ->
normalized, isValidPath -> isValid, etc. Even with user code
breaking, 1) D isn't exactly considered a stable language quite
yet; I'm sure that users expect code breakage with each new
release, and 2) it's trivial to convert code that uses the string
based API to the object based API.
