Memory safety depends entirely on GC ?

[deadalnix via Digitalmars-d]

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.