On Wed, 29 Apr 2009 09:12:52 -0400, Andrei Alexandrescu
<[email protected]> wrote:
Denis Koroskin wrote:
The proposal sound reasonable, but it's hard to follow. I really can't
comment on it because I didn't fully understand it.
[...]
I believe your proposal suffers from it, too. For example, when reading
an introduction, I see this:
┌──────────────┐
│ Overview │
├──────────────┼─────────────────┬─────────────┬──────────────┐
│ Hierarchy │ Description │ Ownership │ Transitivity │
├──────────────┼─────────────────┼─────────────┼──────────────┤
│ scope │ super-interface │ unknown │ deep† │
│ ││└─stack │ current scope │ stack │ implicit │
│ │└──local │ object default │ local-heap │ deep† │
│ ├───shared │ thread safe │ shared-heap │ deep† │
│ └───mobile │ unique objects │ shared-heap │ shallow │
└──────────────┴─────────────────┴─────────────┴──────────────┘
You tell that you introduce 5 different qualifiers but you don't
explain why are they needed. Why not 4, not 3? What problem each of
them solve? All I can do is guess and be proven wrong, that's the most
frustrating.
I agree. I also find the article hard to follow. I'm seeing some
features discussed and all of a sudden "this solves that problem". I
didn't have the time for a closer read, but I think I'll have a hard
time understanding how this proposal works.
The paragraph immediately underneath the summary table explains each type
and its rational. Although in retrospect it might have been better to put
the text before the table.
Here’s an alternative explanation.
For each memory location there’s one type
1) stack, for things allocated on the stack
2) local, for things allocated on the thread local heap
3) shared, for things allocated on the shared heap (i.e. multi-threaded
objects)
Then you have one common type, like const to simplify writing functions
and reduce code bloat:
4) scope, the thing everything ownership type can implicitly cast to
And lastly, I included a unique / mobile type for three reasons.
1) There’s a need for objects private to a shared object. These are
protected by the parent shared object and don’t need or want (slow)
protection of their own. Mobiles are perfect for this, but they should
handle the majority of cases.
2) There is a need to cheaply pass data between threads, which mobiles are
perfect for, and doing so in a library type would require relying on using
unsafe types with usage conventions for safety, which is a recipe for
disaster.
3) There are advantages to have the type system be aware of mobiles, with
regard to generic scope functions (see scope rule 6b)
