Memory safety depends entirely on GC ?

Zach the Mystic via Digitalmars-d digitalmars-d at puremagic.com
Tue Feb 24 06:43:46 PST 2015


On Tuesday, 24 February 2015 at 12:44:54 UTC, Marc Schütz wrote:
> On Monday, 23 February 2015 at 18:16:38 UTC, Andrei 
> Alexandrescu wrote:
>> On 2/23/15 6:56 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= 
>> <schuetzm at gmx.net>" wrote:
>>> These two points have undesirable consequences: All consumers 
>>> such
>>> objects need to be aware of the exact type, which includes the
>>> management strategy (RC, Unique, GC). But this is a violation 
>>> of the
>>> principle of separation of concerns: a consumer shouldn't 
>>> need to have
>>> information about the management strategy, it should work 
>>> equally with
>>> `RefCounted!C`, `Unique!C` and bare (GC) `C`, as long as it 
>>> doesn't take
>>> ownership of the resource.
>>
>> Well I don't know of another way.
>
> Ok, I wrote my reply assuming that you are aware of the various 
> proposals deadalnix, myself and several other people have made 
> in the past, some of them quite specific. But now that I think 
> of it, I don't remember that you were ever directly referring 
> to it in any of your posts. Maybe you just missed it?
>
> As one example, here is what I originally suggested:
> http://wiki.dlang.org/User:Schuetzm/scope
>
> It's not completely up to date, during discussions I gained 
> many useful new insights to simplify it and make things more 
> consistent. It's also part of a bigger picture (deadalnix's 
> ideas about ownership play an important role, too), which 
> unfortunately isn't easy to recognize, because this page has 
> become quite large und unwieldy. I should make a post 
> explaining this.

I'm working on my own idea now. I make scope transitive, because 
it's both memory safe and simple to implement, but doing so may 
cause some things which are actually safe to be considered unsafe 
(but then you could just use @system blocks or @trusted lambdas 
to correct this). Also, I don't think `scope` needs to be part of 
the type.

I'm about 90 percent sure, 10 percent unsure that my system will 
work. I'll have it soon enough. It needs DIP25 to be expanded to 
all reference types (not just `ref`), requires my own DIP71, 
http://wiki.dlang.org/DIP71 for total safety, and possibly one or 
two more additions for a reliable ownership. The only real cost 
is added complexity to function signatures (a la DIP25), which 
can and should be inferred in most cases, assuming we aren't 
crippled by an ancient and subpar linking mechanism which 
requires all this manual marking of signatures all the time.

Stay tuned, sir!


More information about the Digitalmars-d mailing list