Next in Review Queue: The New std.path

[torhu]

On 18.07.2011 15:16, Lars T. Kyllingstad wrote:
> On Sun, 17 Jul 2011 12:30:39 +0200, torhu wrote:
...
>>  joinPath also uses .idup, thus always allocates.  Maybe there could be a
>>  documented allocation policy for the module as a whole?  Copy-on-write
>>  used to be the general rule for Phobos, don't know if that's true
>>  anymore.  For most of the functions in this module, even a single heap
>>  allocation could be more expensive than the rest of what they do.
>
> True.  I've tried keeping allocations to a minimum.  If you see other
> places where an allocation could be avoided (besides the idups), please
> let me know.
>
> I'm not sure what you mean by copy-on-write in this case.  The functions
> in this module never modify the input arrays.

Sorry, don't know why I thought of COW in this case.  Don't heap 
allocate if you don't need to, was what I meant.  Which was because 
.idup was used, so nevermind that now :)

>
>
>>  I've read the discussions about the function names, but I still dare to
>>  make a suggestion of my own.  I feel like joinPath is a bit iffy,
>>  shouldn't it be plural somehow?  What it does is to create a path by
>>  putting pieces together, some paths in their own right, some not.  My
>>  suggestion is to simply call it buildPath.
>
> Good point.  joinPaths would be another option.

I didn't suggest joinPaths, because the inputs are not always paths, 
generally you join things like a path to a directory together with just 
a filename.  Maybe it's ok to call it all just 'paths', I don't know. 
But the output is commonly a path, hence buildPath.  Would be 
interesting to know what other people think, though.