Path as an object in std.path

[Dylan Knutson]

On Thursday, 6 June 2013 at 07:05:52 UTC, Lars T. Kyllingstad 
wrote:
> Paths are usually obtained in string form, and they are 
> normally passed to other functions and third party libraries in 
> string form.  Having to convert them to something else just to 
> do what is, in fact, string manipulations, is just annoying.

Well, when designing Path, I didn't want to add much, if any, 
programmer overhead. Conversion to a Path is trivial: Change the 
type to Path, and 90% of the time it'll just work. The only case 
that comes to mind where a string can't be implicitly 
assigned/converted to a Path is when passing it to a function, in 
which case all it needs to be wrapped in is Path(). Or, have an 
overloaded version that takes a string (which all path using 
functions do now anyways).

> (One of my biggest gripes with boost::filesystem is that 
> conversions between path and string necessitate a copy, which 
> is not a problem with your Path type, so in that respect it is 
> better than Boost's solution.)
>
>
>> [...]
>>
>> Why I think it should be reconsidered for inclusion in the std 
>> (listed in the pull):
>> * Adds a (more) platform independent abstraction for path 
>> strings.
>
> How is this more platform independent?  It is just a simple 
> wrapper around a string, with methods that forward to 
> already-extant module-level functions.

I should have said "makes it easier to be platform independent". 
Normalization is done automatically on comparison. There's 
nothing you can't do with normal std.path functions, but that's 
not the point. It's to be type safe and add convenience.

>> * Path provides a type safe way to pass, compare, and 
>> manipulate arbitrary path strings.
>
> How is it safer?  I would agree with this if it verified that 
> isValidpath(_path) on construction and maintained this as an 
> invariant, but I cannot see that it does.

Type safe. Once you've got a huge program with many concepts 
floating around, you don't want to have to keep track of which 
strings are paths and which aren't, and you don't want to do all 
the specifics like splitting, normalization, and joining with raw 
string functions. This isn't just conjecture either; there are D 
programs in the wild that abstract away path strings because it's 
easier to deal with them that way.
I didn't want to force paths passed in to be valid, because the 
programmer might want an invalid path passed around for whatever 
reason.

>> * It wraps over the functions defined in std.path, so behavior 
>> of methods on Path are, in most cases, identical to their 
>> corresponding module function.
>
> Then what is the added value?

See above. I didn't want to change functionality, just make it 
easier to use.

> As the author of std.path this may come across as hostile or 
> jealous, but I don't see that the proposed change improves 
> anything.

You came off as quite constructive; thank you :-)