Memory safety depends entirely on GC ?

[Andrei Alexandrescu via Digitalmars-d]

On 2/24/15 4:44 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm at gmx.net>" 
wrote:
> As one example, here is what I originally suggested:
> http://wiki.dlang.org/User:Schuetzm/scope

Walter and I discussed this proposal at length several times.

I think it can be made to work. I also think it's overly complicated for 
what it does and that it's not brilliant.

These are the most dangerous designs: complicated, not brilliant, but 
can be made to work - because they end up getting implemented. We want 
to get away without implementing it.

Currently we want to explore DIP25, which we believe has a very good 
price/performance profile (whilst not being brilliant itself), and its 
impact on designing safe struct types. It is our suspicion that DIP25 is 
all we need for making involved struct types safe. If that's the case, 
that paves the road toward safe class types using reference counting 
with very small language changes.

There will be stragglers, such as taking slices into stack-allocated 
statically-sized arrays. At that point the question will be whether we 
can implement that as a @safe struct, we need a language change, or we 
can just live with it (after all, using stack-allocated arrays in safe 
code is a rather niche use).

So the short answer is: yes, I've studied your proposal and I don't 
think it's good enough. Furthermore I don't think there are small 
changes to it that will make it good enough. This is not personal and 
please don't take offense over that. In contrast, I think DIP25 is good 
(partly because it's deceptively simple) and I want to pursue it and its 
consequences.


Andrei