On Monday, 17 November 2014 at 08:04:44 UTC, Walter Bright wrote:
Nice article.
Some observations:
1. I don't understand the difference between 'unique', 'owned'
and 'isolated'. (Some other systems use 'isolated'.) Is there a
difference?
2. I suspect that 'owned' does not need to be a type qualifier
- it can be a storage class much like 'ref' is. This makes for
a much simpler implementation.
3. Taking it a step further, I suspect that 'owned' can be
implemented as a library type, ala owned!T, with only a smidgen
of compiler help.
Ok, I'm gonna respond in reverse order, so I can use one answer
as a starting point for the next one.
3. This is not doable as a library type. The proposal interact
with @nogc, pure function and exception handling. There is no way
to make it @safe as a librayr type as well, consider:
static A statica;
class A {
void foo() {
statica = this;
}
}
owned!A owneda = ...
owneda.foo();
We want the compiler to be able to determine what is owned as
much as possible and insert the right runtime magic calls to make
that work.
2. I'm not sure if that is enough to make it work. It is worth
investigating. It is gonna be much more limited than what I have
in mind.
How do you see this working with fields in struct/classes for
instance ?
1. owned is simply a refined version of isolated. The reserach
team comming up with isolated did it for concurrency reasons, and
it is useful for this, but my proposal include a memory
management aspect, that isolated lacks. So I figured out I'd come
up with a better name.
It is different from unique in the sense that there can be
multiple references to the owned object. For instance:
class A {
A next;
}
pure auto foo() {
auto a1 = new A();
auto a2 = new A();
a1.next = a2;
a2.next = a1;
return a1;
}
Here the returned reference is owned. But it is not unique (a2
also have a reference to that object). Owned indicate that you
enter into a new island. Everything reached transitively from
there is assumed to be in the same island unless you cross a new
owned or immutable reference.
That means code like:
owned(A) bar() {
auto a = foo();
auto next = a.next;
// At this point, we have 2 local reference to the island.
// Returning is an operation that consume. It would
invalidate all local reference to that island. That is ok here as
we are returning and not using them anyway.
return a.next;
}
is valid. The type system here is not checking that a reference
to an object is unique, but that who owns the island is know (and
the island only has one owner at a time). It is a more generic
and more powerful construct, and I don't think it come at extra
complexity for the user compared to unique. However, it
definitively means more work on our side.
