Use case: eliminate hidden allocations in buildPath

[Manu]

On 5 December 2013 10:13, Michel Fortin <michel.fortin at michelf.ca> wrote:

> On 2013-12-04 23:14:48 +0000, Andrei Alexandrescu <
> SeeWebsiteForEmail at erdani.org> said:
>
>  Walter and I were talking about eliminating the surreptitious allocations
>> in buildPath:
>>
>> http://dlang.org/phobos/std_path.html#.buildPath
>>
>> 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).
>>
>> It's a generous design space, so although we have a couple of ideas let's
>> hear others first.
>>
>
> 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.
>

Allocator as the first argument? This is so you can use UFCS on the
allocator to make the call?
I think it maybe makes sense for a function that takes an output range to
receive it as the first argument for this reason:
 outputRange.myFunction(); // I'm not sure if I like this, not sure it's
communicating the right process... but maybe people find it convenient?

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).

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. :-/


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?).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131205/96b2a8d3/attachment.html>