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.
