Path as an object in std.path

Jonathan M Davis jmdavisProg at gmx.com
Wed Jun 5 13:34:27 PDT 2013


On Wednesday, June 05, 2013 22:19:21 Dylan Knutson wrote:
> > 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).

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.

> This makes its integration into existing codebases/Phobos
> literally as easy as
[snip]

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. If we add a Path struct, then we have two ways to do the same 
thing, and we're going to have a division among APIs as to which way to handle 
paths. And I think that we'll be very much worse of because of it. While there 
is value in having a path struct rather than a string, I don't think that it's 
worth the extra confusion and division that it'll cause. If we were going to 
have a path struct, we should have done that in the first place rather than 
using strings.

- Jonathan M Davis


More information about the Digitalmars-d mailing list