We need a typesystem-sanctioned way to cast qualifiers away
Andrei Alexandrescu via Digitalmars-d
digitalmars-d at puremagic.com
Fri Jun 19 17:06:15 PDT 2015
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.
2. Allocation: functional containers carry with them a reference to an
IAllocator interface, which tells them how to do memory allocation.
Somewhat paradoxically, it is sometimes necessary to allocate memory
even for immutable objects. For example, in the concatenation "value ~
list", the list's allocator must be used.
Again, the reference to IAllocator must be unqualified even inside an
otherwise qualified object.
These are matters of implementation internals and I'm perfectly
comfortable that it's necessary to overstep the boundaries of the type
system. The only matter is finding a way to inform the type system that
it must make legal certain casts.
Andrei
More information about the Digitalmars-d
mailing list