Poll: a nonstate keyword

[Janice Caron]

On 01/06/2008, Fawzi Mohamed <fmohamed at mac.com> wrote:
>  If the library solution is efficient then and the use cases I identified
> are covered then I see no need for the keyword (and keeping the language
> simple and ensuring the the users understand the style of the language is
> worth some effort).

So let's make a list of all of the use-cases that we can collectively
think of. These are the ones I can come up with:

(1) caching
(2) reference counting
(3) intrusive linked lists (also intrusive binary tree nodes, etc).
(4) "is associated with"

Any more?



>  If the compiler really gets more aggressive in ensuring that invariant is
> constant then the only possible solution will be fully external (id_number
> in the object

No need for that. The hashtable can be keyed on "this".

> +cleanup handle in destructor,

which would be transparent

> and external hashtable
> mutable_state[id_number]),

It wouldn't need to be external, it could be a static member variable.
(I think it would have to be, if we want cleanup to be transparent).
So you'd end up with something like

    class A
    {
        mixin Cache!(int) x;
    }

    const a = new A;
    a.x = 3; // OK


>it would be a pity to have to pay this extra
> cost when most cases in which this is used are related to the need of being
> more efficient.

If the calculation is faster than a hashtable lookup, then you
shouldn't be caching anyway. If the calculation is slower than a
hashtable lookup, then with a hashtable lookup, you still win.

I'm not so sure about the other use cases. That's why it's a good idea
to make a list, and weigh up the pros and cons of each possible
solution.