Disadvantages of ARC

[Adam D. Ruppe]

On Thursday, 6 February 2014 at 16:40:32 UTC, Andrei Alexandrescu 
wrote:
> The issue here is that Phobos functions need to document 
> whether e.g. they return memory that can be deallocated or not. 
> Counterexamples would be returning static strings or subslices 
> of allocations.

This is why specifying ownership by type is important. It 
documents the need, it makes sure the information doesn't get 
dropped, and it can automatically manage the details (via RAII).

Something that mallocs should return Malloced!T which calls the 
appropriate free (specified by the allocator) in the destructor. 
GC should return GC!T. Refconted should return RefCounted!T, and 
so on.

alias this can easily allow interoperability... though, of 
course, not escaping things incorrectly would have to be taken 
care of, either manually or automatically. I keep coming back to 
this because it cannot be avoided, except by GC through and 
through. If the language does not help with this, it doesn't mean 
the complexity goes away. It just means it is moved onto the 
(fallible) programmer.

> I think a crack should be given to the user to install their 
> own allocator (per thread and/or shared). Perhaps we can limit 
> that to the startup stage, i.e. before any allocation takes 
> place.

You could always link in your own _d_allocmemory, etc. I wouldn't 
do this, it will make things hard to get right, but it is very 
easy  - just add the functions to your main project. the linker 
will prefer your functions to the druntime functions.