[cap-talk] Composability and RAII

[Rob Meijer]

On Mon, March 7, 2011 07:28, William ML Leslie wrote:
> On 7 March 2011 17:03, Rob Meijer <capibara at xs4all.nl> wrote:
>> The other cases are where C++ RAII also breaks down. I tried to argue
>> that
>> cPython (reference counted GC) shows that a combination of reference
>> counted GC with RAII can be a good solution there.
>
> It works for a certain subset of resource usage, and file usage is one
> case where it has worked fairly well traditionally. But, as the zen of
> python says, explicit is better than implicit.  And especially where
> the GC is concerned, because programmers have difficulty reasoning
> about its behaviour in even small projects.

An other controversial aspect of C++ that I find rather interesting with
respect to this is 'auto_ptr'. Basic consensus amongst C++ people is that
auto_ptr should mostly be avoided for the reason that a copy transfers
ownership (and is in fact a move). I think however that this property is
pretty interesting from a POLA and message passing concurrency point of
view. The fact that a copy transfers ownership (and makes the original
unusable) seems an interesting way to further reduce the problems of
shared resources. The C++ peoples dislike for auto_ptr is probably
justified, but it exposes one interesting flaw (from a POLA point of view)
in current languages: The lack of convenient 'move' semantics. I believe
the upcoming C++0x standard is somehow addressing move semantics in a way
that is probably pretty low level and incompatible with most other
languages. I'm not sure if move semantics could for example be made
compatible with GC languages at all. If it could, it might be very
interesting an addition to the least authority arsenal of o-cap languages
indeed.
I haven't thought it trough much, but possibly adding some form of move
semantics to the mix might either reduce the amount of type 2 problems or
might help in solving them. Just a wild thought.