The "no gc" crowd

[Andrei Alexandrescu]

On 10/8/13 9:29 AM, ponce wrote:
> On Tuesday, 8 October 2013 at 16:22:25 UTC, Dicebot wrote:
>> It is not overblown. It is simply "@nogc" which is lacking but
>> absolutely mandatory. Amount of hidden language allocations makes
>> manually cleaning code of those via runtime asserts completely
>> unreasonable for real project.
>
> Hidden language allocations:
> - concatenation operator   ~
> - homogeneous arguments   void (T[]... args)
> - "real" closures that escapes
> - array literals
> - some phobos calls
>
> What else am I missing?
> I don't see the big problem, and a small fraction of projects will
> require a complete ban on GC allocation, right?

It's clear that the perception of GC will not change soon, however good 
or not the arguments may be as applied to various situations and 
projects. It is also a reality that our GC is slow.

So we need to attack this problem from multiple angles:

* Make RefCounted work as immutable data. There will be a casting away 
of immutability in there, but since it's under the aegis of the standard 
library, it is admissible. All implementations must ensure RefCounted works.

* Add reference counted slice and associative array types that are as 
close as humanly possible to the built-in ones.

* Advertise all of the above in a top module such as std.refcounted. 
It's amazing how many D programmers have no idea RefCounted even exists.

* Review all of Phobos for hidden allocations and make appropriate 
decisions on how to give the user more control over allocation. I have 
some idea on how that can be done, at various disruption costs.

* Get Robert Schadek's precise GC in. Walter and I have become 101% 
convinced a precise GC is the one way to go about GC.

I'm up to my neck in D work for Facebook so my time is well spent. We 
must definitely up the ante in terms of development speed, and pronto.


Andrei