On Tuesday, 24 February 2015 at 19:20:37 UTC, Andrei Alexandrescu
wrote:
Compared to what ?
There is no comparison involved. The proposal is too
complicated for what it does. -- Andrei
There is always a comparison involved. Comparison options
includes:
- Not solving some of the issues we have and call it a day.
- Add simpler solution dedicated to each of these problems.
The problems we are talking about are:
- safe RC
- fast GC by using type qualifier guarantee.
- less reliance on GC by producing less garbage.
- enforcing type qualifier constraint.
- enabling more code to be @nogc (especially exception)
- being able to delegate the memory management policy to the
user.
- immutable and shared building.
- manipulating object of limited lifetime (DIP25 solve this
partially).
- `unique` message passing .
- safe parallelism on graph of object instead of only value
types.
- lock on graph of objects (shared containers).
Now it is clear that we can come up with simpler solution for
some of these problem than whatever all encompassing solution
would be. It is also clear that is is not possible to get a set
of simpler solution that is, as a whole, simpler than an all
encompassing solution. That means that some of the above
mentioned point must be acknowledged as not going to be fixed.
It is also to be noted that these above mentioned problems are
not orthogonal. For instance, getting various GC optimizations in
that take advantage of type qualifiers guarantee require that
these guarantee are enforced. To get these constraints enforced,
you need to be able to build immutable and/or shared in a way
that don't break these constraints, and so on.
