Now,some people think D is a 'Memory safety depends entirely on GC' system Language,what do you think?

On Sat, 21 Feb 2015 10:00:06 +0000, FrankLike wrote:

> Now,some people think D is a 'Memory safety depends entirely on GC' system Language,what do you think?

this is wrong.

On Saturday, 21 February 2015 at 10:00:07 UTC, FrankLike wrote:
> Now,some people think D is a 'Memory safety depends entirely on GC' system Language,what do you think?

It's kind of right, at the moment, since @nogc D is still quite difficult to use, mostly due to exceptions and library artifacts. Both of these can be solved though.

On Saturday, 21 February 2015 at 18:06:57 UTC, Peter Alexander wrote:
> On Saturday, 21 February 2015 at 10:00:07 UTC, FrankLike wrote:
>> Now,some people think D is a 'Memory safety depends entirely on GC' system Language,what do you think?
>
> It's kind of right, at the moment, since @nogc D is still quite difficult to use, mostly due to exceptions and library artifacts. Both of these can be solved though.

That wouldn't make @nogc safe in any way.

On Saturday, 21 February 2015 at 18:42:54 UTC, deadalnix wrote:
> On Saturday, 21 February 2015 at 18:06:57 UTC, Peter Alexander wrote:
>> On Saturday, 21 February 2015 at 10:00:07 UTC, FrankLike wrote:
>>> Now,some people think D is a 'Memory safety depends entirely on GC' system Language,what do you think?
>>
>> It's kind of right, at the moment, since @nogc D is still quite difficult to use, mostly due to exceptions and library artifacts. Both of these can be solved though.
>
> That wouldn't make @nogc safe in any way.

@safe @nogc

:-)

(I rewrote the post a few times. Originally I just wrote "mark main @safe @nogc and you're fine", but I think it's a bit misleading since @nogc is still difficult to use, so I wrote about that instead and forgot to mention @safe at all. Thanks for pointing out.)

On Saturday, 21 February 2015 at 19:38:02 UTC, Peter Alexander wrote:
> @safe @nogc
>
> :-)
>
> (I rewrote the post a few times. Originally I just wrote "mark main @safe @nogc and you're fine", but I think it's a bit misleading since @nogc is still difficult to use, so I wrote about that instead and forgot to mention @safe at all. Thanks for pointing out.)

free is an unsafe operation. Unless you don't allocate at all or choose to leak everything, you won't be able to be safe and nogc.

The only way out that I know of is an ownership system.

On Saturday, 21 February 2015 at 20:13:26 UTC, deadalnix wrote:
> On Saturday, 21 February 2015 at 19:38:02 UTC, Peter Alexander wrote:
>> @safe @nogc
>>
>> :-)
>>
>> (I rewrote the post a few times. Originally I just wrote "mark main @safe @nogc and you're fine", but I think it's a bit misleading since @nogc is still difficult to use, so I wrote about that instead and forgot to mention @safe at all. Thanks for pointing out.)
>
> free is an unsafe operation. Unless you don't allocate at all or choose to leak everything, you won't be able to be safe and nogc.
>
> The only way out that I know of is an ownership system.

malloc+free can be trusted if wrapped in something like a ref counted pointer, no?

On 2/21/15 2:13 PM, Peter Alexander wrote:
> On Saturday, 21 February 2015 at 20:13:26 UTC, deadalnix wrote:
>> On Saturday, 21 February 2015 at 19:38:02 UTC, Peter Alexander wrote:
>>> @safe @nogc
>>>
>>> :-)
>>>
>>> (I rewrote the post a few times. Originally I just wrote "mark main
>>> @safe @nogc and you're fine", but I think it's a bit misleading since
>>> @nogc is still difficult to use, so I wrote about that instead and
>>> forgot to mention @safe at all. Thanks for pointing out.)
>>
>> free is an unsafe operation. Unless you don't allocate at all or
>> choose to leak everything, you won't be able to be safe and nogc.
>>
>> The only way out that I know of is an ownership system.
>
> malloc+free can be trusted if wrapped in something like a ref counted
> pointer, no?

There's more to it, e.g. access to the underlying raw pointer must be carefully restricted. -- Andrei

On Saturday, 21 February 2015 at 22:13:09 UTC, Peter Alexander wrote:
> malloc+free can be trusted if wrapped in something like a ref counted pointer, no?

Foo bazoom;

class Foo {
    void bar() {
        bazoom = this;
    }
}

void foo() {
    RefCounted!Foo f = ...
    f.bar();

    // bazoom is now a dandling pointer.
}

On Sunday, 22 February 2015 at 04:19:32 UTC, deadalnix wrote:
> On Saturday, 21 February 2015 at 22:13:09 UTC, Peter Alexander wrote:
>> malloc+free can be trusted if wrapped in something like a ref counted pointer, no?
>
> Foo bazoom;
>
> class Foo {
>     void bar() {
>         bazoom = this;
>     }
> }
>
> void foo() {
>     RefCounted!Foo f = ...
>     f.bar();
>
>     // bazoom is now a dandling pointer.
> }

I see, thanks.

Is assigning 'this' from a member function the only problem case?