We need a typesystem-sanctioned way to cast qualifiers away

[via Digitalmars-d]

On Saturday, 20 June 2015 at 00:07:12 UTC, Andrei Alexandrescu 
wrote:
> I've gained a crapton of insight while working on collections. 
> It's amazing.
>
> One interesting aspect is the interaction of mutable and 
> functional collections with the type qualifiers "const" and 
> "immutable". I managed to navigate around issues quite nicely, 
> with two exceptions:
>
> 1. Reference counting: it's mutation underneath an immutable 
> appearance. For a good while I'd been uncomfortable about that, 
> until I figured that this is the "systems" part of D. Other 
> languages do use reference counting, but at the compiler level 
> which allows cheating the type system. It is somewhat fresh to 
> attempt a principled implementation of both reference counting 
> and safe functional collections, simultaneously and at library 
> level.
>
> My conclusion is that changing the reference count in an 
> otherwise immutable structure is an entirely reasonable thing 
> to want do. We need a way to explain the type system "even 
> though the payload is const or immutable, I'll change this 
> particular uint so please don't do any optimizations that would 
> invalidate the cast". The user is responsible for e.g. atomic 
> reference counting in immutable data etc.

A similar situation is hashing: Functional (immutable) 
collections could be used as hash keys. If you want to use 
non-trivial hash functions in a pure immutable collection, you 
either calculate up front "just in case" or reevaluate each time. 
Caching (lazy evaluation) is off the table.

Then again, maybe you navigated around that one already.