Memory safety depends entirely on GC ?

[via Digitalmars-d]

On Sunday, 22 February 2015 at 14:54:26 UTC, Peter Alexander 
wrote:
> On Sunday, 22 February 2015 at 14:49:37 UTC, Marc Schütz wrote:
>> On Sunday, 22 February 2015 at 14:41:43 UTC, Peter Alexander 
>> wrote:
>>> 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?
>>
>> No. There's also returning the reference from a member 
>> function, storing it in a passed-in reference (pointer, ref, 
>> out or slice), and passing it to other functions that in turn 
>> leak the reference, as well as throwing it. And leaking 
>> closures containing the reference.
>>
>> That's all that I can think of now...
>
> Sorry, I meant things other than moving this from a member 
> function to somewhere else, i.e. the RefCounted shouldn't leak 
> the pointer itself in any other way. Just wondering if there 
> are ways to avoid the problem by making 'this' unescapable in 
> certain situations.

Ah, ok. But escaping the reference is unavoidable if you don't 
want to pass the RC object around (and you don't, because it's 
expensive). And the only safe way to escape it is an ownership 
system.