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
