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 :-)
