Smart pointers instead of GC?

[Martin Cejp]

On Sunday, 2 February 2014 at 05:12:05 UTC, Frank Bauer wrote:
> On Sunday, 2 February 2014 at 04:23:35 UTC, Adam Wilson wrote:
>> Maybe, but my point is that even with no allocations in 
>> phobos, you'd have to verify that ALL the libraries you use 
>> don't GC allocate. That's why so many people in the ARC camp 
>> want to make it the only GC system in D. Multiple GC systems 
>> increase your cognitive load considerably.
>
> Good point. What we DON'T want is a library that comes in 
> MySuperLib-GC, MySuperLib-ARC, MySuperLib-Owning and 
> MySuperLib-Borrowed flavors.
>
> But I don't think that is necessary.
>
> A library function would typically take arguments by reference 
> aka as a Borrowed(T). GC(T), ARC(T) and Owning(T) convert 
> equally well to Borrowed(T). So somebody who uses only GC(T) in 
> her code could use the library just as easily as someone who 
> prefers Owning(T). The library would be compatible with the 
> two, because it does not own the (reference to the) passed 
> object. GC(T) or Owning(T) at the call site would free the 
> object automatically (at the next collection cycle or when 
> leaving the scope). Everybody is happy!
>
> All that is left for the caller is to choose whether she wants 
> to use a library that uses GC *internally*. Interaction is 
> possible in every combination:
>
> 1. I use GC(T),     the library uses GC(T) internally     -> 
> works (with GC),
> 2. I use Owning(T), the library uses GC(T) internally     -> 
> works (with GC),
> 3. I use GC(T),     the library uses Owning(T) internally -> 
> works (with GC),
> 4. I use Owning(T), the library uses Owning(T) internally -> 
> works (w/o GC).

This exists. It's called C++.

I've pretty much given up on GC and do all my allocations in the 
real-time path manually. In a game, there shouldn't be that much 
stuff to allocate once live, anyway.