<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 5 December 2013 10:13, Michel Fortin <span dir="ltr"><<a href="mailto:michel.fortin@michelf.ca" target="_blank">michel.fortin@michelf.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 2013-12-04 23:14:48 +0000, Andrei Alexandrescu <<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a><u></u>> said:<br>

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Walter and I were talking about eliminating the surreptitious allocations in buildPath:<br>
<br>
<a href="http://dlang.org/phobos/std_path.html#.buildPath" target="_blank">http://dlang.org/phobos/std_<u></u>path.html#.buildPath</a><br>
<br>
We'd need to keep the existing version working, so we're looking at adding one or more new overloads. We're looking at giving the user the option to control any needed memory allocation (or even arrange things such that there's no memory allocated at all).<br>

<br>
It's a generous design space, so although we have a couple of ideas let's hear others first.<br>
</blockquote>
<br></div></div>
Allow an allocator as the first argument. Then pass an allocator that uses preallocated memory (or any other strategy that does not really need to allocate). While technically the allocator still "allocates" memory, since you control the allocator it does it the you can redefine "allocate" to not allocate.<br>
</blockquote><div><br></div><div>Allocator as the first argument? This is so you can use UFCS on the allocator to make the call?</div><div>I think it maybe makes sense for a function that takes an output range to receive it as the first argument for this reason:<br>
</div><div> outputRange.myFunction(); // I'm not sure if I like this, not sure it's communicating the right process... but maybe people find it convenient?</div><div><br></div><div>An overload that receives an allocator though, I'd probably make the allocator the last argument, this way it can have a default arg that is the default GC allocator, thus eliminating the other (original?) overload of the function which receives neither an output range or an allocator (using the GC intrinsically).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Here's a funny thought: allow plain arrays to be *typed* allocators through UFCS, just like arrays are ranges. If you have an array of chars, then "allocating" from it will simply return a slice and "bump the pointer" by becoming the remaining unused slice. The big problem with buildPath is that it won't work with overloading because your allocator has the same type as the other parameters. You'll need to wrap it in some kind of allocator shell. :-/</blockquote>
<div><br></div><div>I'm not sure I like this idea. I think I'd prefer to see 2 overloads, one that receives an output range, and one that receives an allocator (which may default to a GC allocator?).</div></div></div>
</div>