Memory safety depends entirely on GC ?

via Digitalmars-d digitalmars-d at puremagic.com
Tue Feb 24 09:47:40 PST 2015


On Tuesday, 24 February 2015 at 16:18:45 UTC, Andrei Alexandrescu 
wrote:
> 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.

I'm certainly not offended. I don't think the proposal is 
"brilliant" either, it was meant as a starting point for 
discussions, not as a completely finished proposal aka DIP. Out 
of interest, because that will be crucial for the further 
development: are you completely opposed to any kind of ownership 
system, or is it something specific about this particular 
proposal that you don't like?


More information about the Digitalmars-d mailing list