There's a significant difference between a type which has a
value and units and
one which is basically just a string or array of strings
wrapped by another
type. Not that a Path struct is without value, but I think that
there's a very
large difference in the amount of value that the two provide.
AFAIK, very few
bugs are caused by treating paths as strings, but there are a
lot of time-
related bugs out there caused by using naked values instead of
values with
units.
Dub is forced to define its own separate Path type because, as
its author states, using a string to represent a path "more often
than not results in hidden bugs."
(https://github.com/rejectedsoftware/dub/issues/79). Representing
a path is just fine in a small script, but the moment you've got
to handle stuff like path comparison, building, and general
manipulation, you're better off defining an abstraction for it.
See, this is exactly the sort of thing I'm afraid of. I don't
want to have to
have arguments over whether a particular function should accept
a path as a
string or a struct. Right now, we have one way do to it, so
it's clear, and it
works just fine.
I see no problem with just keeping Phobos as it is, it was just a
suggestion to make use of new functionality. A function that
takes a string can accept a Path *or* a string, and it'll work
just fine, thanks to subtyping.
void bar(Path path) { return; }
void foo(string str) { return; }
Path p = `baz\quixx`;
bar(p);
foo(p);
So there doesn't have to be an argument over what a function
should accept; that's up to the function's internal
implementation. From the outside, it'll accept both.
