RFC: moving forward with @nogc Phobos

[Sean Kelly via Digitalmars-d]

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