alias annotations - unque / owned / shared / lent

[Janice Caron]

On 2/1/08, Jason House <jason.james.house at gmail.com> wrote:
> I probably should have included the full URL
> http://archjava.fluid.cs.cmu.edu/papers/oopsla02.pdf
>
> Both the const challenge and string alias invariant threads have mentioned "Unique()" qualifications on types.  The paper seems to expand this in a coherent type system that may be compatible with D.

I read it.

I do like it, but I suspect it might be too complex to explain. Even
justifying /one/ new keyword (unique) is hard. To ask Walter to add
four (unique, owned, shared, lent), might be asking too much.

One thing worth noting is that Java doesn't have const. That means
that the (unique, owned, shared, lent) system has to compensate for
const's non-existence. Since D /does/ have both const and invariant,
it seems to me that the requirement for those other categories goes
away.

In the D system, there are currently three kinds of constancy: mutable
(i.e., no qualifier at all), const, and invariant. Three is an odd
number for computers. Two bits has four possibilities, not three. I
believe unique fills the missing slot.

Imagine a diamond shape. "unique" goes at the top; "mutable" goes at
the left; "invariant" goes at the right; and "const" goes at the
bottom. You can implicit cast by moving downwards, but explicit casts
are required to move upwards.

Another way of looking at it: number the constancy kinds:
unique = 0
mutable = 1
invariant = 2
const = 3

Now the can figure out what can cast into what with bitwise binary operators.

    A can implicitly cast to B iff ((A || B) == B).
    The common type that A and B can both implicitly cast to is (A || B)
    They type that can implicitly cast to both A and B is (A && B)

To my mind, a four-kinds-of-constancy system is actually simpler to
implement than a three-kinds-of-constancy system.

That is not to say that the (unique, owned, shared, lent) system is
bad. It is well thought out, well argued, and it looks like it ought
to work. But we'd have to make it work /in addition to const and
invariant/, so now we'd have six keywords representing many states.
How would they interact with each other? I shared+mutable different
from shared+const, or does shared imply const?

I think that, for the (unique, owned, shared, lent) system to work,
we'd have to ditch const. (That may be a good thing - who knows?) But
Walter is definitely going to want to keep invariant - because it's
the key to lots of optimisation.