Persistent list

[Observer via Digitalmars-d]

On Monday, 16 November 2015 at 16:58:24 UTC, Lionello Lunesu 
wrote:
> If it's RC we want, then @mutable is an axe when what we need 
> is a scalpel.
>
> The non-observability comes from the fact the refcount is 
> changed when the caller has lost its (const) reference and 
> constness is a moot point. Changing refcount is fine now, 
> provided the object is not immutable. As far as other 
> outstanding const references go, these already expect changes 
> to happen.
>
> This is what makes refcount special and provably safe to 
> mutate. As long as we can ensure the object is not immutable, 
> the object is allowed to change its own refcount. But refcount 
> needs to be special cased, somehow, or else we'll end up with 
> some C++ like `mutable`.

I'm not a compiler or language-design guy, but something strikes
me as odd about this whole discussion.  It seems to me that a lot
of it depends on a presumption that one wants the refcount field
to be user-visible, and that therefore it must also have some
user-visible type and perhaps some attributes.  But at bottom,
doesn't a refcount field behave more like a vptr for a class
instance, which is there in the underlying storage model but is
not directly user-visible?  Or similar to whatever metadata is
used for the start/end pointers of a dynamic array?  As such, is
there any reason for a refcount to be user-visible in the first
place, other than to the compiler-internals implementor?  I have
to wonder whether a refcount field could be appended to the data
payload via some sort of @rc attribute instead of as an explicit
class/struct member, and perhaps referenced via some implicit
pseudo member when the field needs to be manipulated.  Then there
perhaps wouldn't need to be any requirement to define any new
kinds of storage categories for this field, in the same way that
there isn't an explicit storage category for a vptr field.

I could be all wet here with such ideas, but I'm just wondering 
...