On Wednesday, 1 October 2014 at 08:55:55 UTC, Andrei Alexandrescu
wrote:
On 9/30/14, 9:10 AM, Sean Kelly wrote:
Quite honestly, I can't imagine how I could write a template
function in D that needs to work with this approach.
You mean write a function that accepts a memory management
policy, or a function that uses one?
Both, I suppose? A static if block at the top of each function
that must be aware of every RC type the user may expect? What if
it's a user-defined RC type and this function is in Phobos?
As much as I hate to say it, this is pretty much exactly what
C++
allocators were designed for. They handle allocation, sure,
but they
also hold aliases for all relevant types for the data being
allocated.
If the MemoryManagementPolicy enum were replaced with an alias
to a type that I could use to at least obtain relevant
aliases, that would be something. But even that approach
dramatically complicates code that uses it.
I think making MemoryManagementPolicy a meaningful type is a
great idea. It would e.g. define the string type, so the code
becomes:
auto setExtension(alias MemoryManagementPolicy = gc, R1, R2)(R1
path, R2 ext)
if (...)
{
MemoryManagementPolicy.string result;
...
return result;
}
This is a lot more general and extensible. Thanks!
Why do you think there'd be dramatic complication of code?
(Granted, at some point we must acknowledge that some egg
breaking is necessary for the proverbial omelette.)
From my experience with C++ containers. Having an alias for a
type is okay, but bank of aliases where one is a pointer to the
type, one is a const pointer to the type, etc, makes writing the
involved code feel really unnatural.
The thing is, again, we must make some changes if we want D to
be usable without a GC. One of them is e.g. to not allocate
built-in slices all over the place.
So let the user supply a scratch buffer that will hold the
result? With the RC approach we're still allocating, they just
aren't built-in slices, correct?
That would be overreacting :o).
I hope it is :-)
