On Sat, 25 Dec 2010 14:23:47 -0700, Alex Khmara <[email protected]>
wrote:
On Sat, 25 Dec 2010 14:42:48 -0000, bearophile
<[email protected]> wrote:
spir:
I would enjoy to see a concrete, meaningful, example.
Often enough my class/struct members are arrays, and often I'd like the
compiler to help me be more sure their memory is not shared (with a
slice, for example) with something outside the instance. See below.
It seems your point is to avoid sharing ref'ed elements --which is
precisely the purpose of referencing, isn't it?
That's one of the purposes of references, but there are other purposes.
A dynamic array is allocated on the heap through a kind of fat
reference so you are able to change its length. Objects in D are always
managed by reference, so you have no choice.
What is the sense of having referenced elements if the references are
not to be shared?
They are owned by the class instance :-) And even if you use emplace or
scoped from Phobos, you still have a reference, so @owned is useful
even for scoped objects.
Then, you would need a tag like @owned to give back value semantics to
referenced elements... Correct?
@owned doesn't change the semantics and probably the resulting binary
is unchanged. Its purpose is just to disable certain undesired (and
buggy) behaviours, to keep class instance the only owner of the
referenced object/array.
What about the opposite (much rarer) case:
It's another thing.
Googling should point you to 2-3 articles by Bertrand Meyer
I remember something by Meyer, but I don't remember if he was talking
about instance ownership. I will read something again.
Bye,
bearophile
I don' understand how this can be implemented in more complicated cases:
class X {
@owned private int[] foo;
int[] f1() {
auto fooSlice = foo[0...3]; // is this valid?
someExternalFunc(foo); // is this allowed?
someExternalFunc(fooSlice) // how about this?
return someFuncReturningArrayArg(fooSlice); // how to detect
this?
}
}
It seems that @owned can work only in very primitive cases - otherwise
complex escape
analysis needed, and I even do not know if it will help. May be, if only
pure function will be
allowed to accept @owned arguments, it will be ok, but power of this
feature will be
severely limited in this case.
This @owned is very similar to previous 'scope' proposals (and oddly
dissimilar to previous owned proposals). To answer your question, under
previous proposals the scope keyword would allow you to declare that a
variable doesn't escape the current scope. So you could define external
functions that would take a 'scope int[]' and be guaranteed that it
wouldn't escape. (returning scoped values has to obey certain restrictions)
The previous 'owned' proposals are a bit more general. Owned types allow
you parameterize a type on a variable, which sounds complex, but what it
means in terms of the runtime, is that all objects in the same ownership
group shared the same monitor. The big advantage is that inside a
synchronized method you don't have to synchronize other 'owned' objects of
the same type. It also makes this like unique a lot more viable, since you
can now define trees, etc.
