Memory safety depends entirely on GC ?

[deadalnix via Digitalmars-d]

On Monday, 23 February 2015 at 18:16:38 UTC, Andrei Alexandrescu 
wrote:
> That's not feasible. Code that assumes the class object will 
> live forever can simply do things that are not allowed to code 
> that must assume the object will go away at some determined 
> point. Consider this which I just posted:
>
> class Widget
> {
>     private char name[1024];
>     char[] getName() { return name[]; }
>     ...
> }
>
> The typechecker must WHILE COMPILING WIDGET, NOT ITS CLIENT 
> know whether getName() is okay or not.
>

Let's use that exemple.

> Well I don't know of another way.
>

I'm not sure if this is dishonest, but proposal has been made in 
this newgroup, by various person,s including myself.

Let's get around the major concept.

name is owned by the widget instance (let's call it w). That 
means its lifetime is the same as w's lifetime.

w's owner will provide its lifetime. If w's owner is the GC, then 
its lifetime is infinite. if w's owner is some refounting system, 
its lifetime is defined by when the refcounting system will 
destroy it.

getName here assumes the lifetime of the object is infinite. 
That's ok. It means you won't be able to call it when it is owned 
by a RC system. If you want to be able to do so, you'll ned have 
a way to specify the lifetime of the returned slice. For instance 
:

class Widget {
     private char name[1024];
     scope(char[]) getName() scope { return name[]; }
     ...
}

In this case, you can call the method when w is owned by a RC 
system, as it is now explicit to the caller that the lifetime of 
what is returned and the compiler can ensure the slice do not 
exceed its lifetime (ie w's lifetime).

This require to be able to express lifetime and preferably 
ownership as well. So far, what I feel from you and Walter is the 
will to not go into that direction and instead created a myriad 
of hacks for various special cases. I do think this is wrong 
headed and generally not the way forward. Languages should 
provide the most generic and powerful tool so that interesting 
schemes can be implemented on top of it.