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
