Re: A hole in Ada type safety

[Florian Weimer <fw@deneb.enyo.de>]

* Dmitry A. Kazakov:

> Then a built-in access-to-component type might be a better solution. It
> would eliminate a need for components to be aliased. Since the offset is
> statically known (or a function that calculates it is), it need not to be
> kept anywhere.

You'd still have the safety hazard with the reference to the outer
record.  There are is some impact on encapsulation which has to be
considered.  And it's not going to help with the original problem (a
safer replacement for discriminants with defaults).

> OK, but you need to create the first reference somehow.

Uhm, I had imagined you'd use an allocator for that.  The whole thing
is meant to be a bit similar to access values.

>>> IMO weak references are quite useless if do not support notifications (when
>>> the last strong reference is removed). I.e. you need a list of weak
>>> reference holders.
>> 
>> I think they are supposed to be used for parent pointers in trees, for
>> instance, to avoid the cycle issue.  Not so much for finalization.
>
> I rather use: parent-->child is a plain pointer, child-->parent is a
> strong reference.

Dereferencing a weak pointer incurs a run-time check and operations on
the counters (if reference counting is used), and the parent pointer
is only needed for some traversal operations, so weak pointers upwards
seem the way to go.

> The most interesting cases for weak references are in the first line
> finalization notification. E.g. cached objects.

You would get that with controlled types.

I don't think weak references work for caches if you have reference
counts and precise finalization because the last reference to the
cached object goes away too soon.  There are different types of
references (sometimes called "weak", too) which are cleared by the
memory manager if it cannot satisfy an allocation request, but this
raises awkward concurrency issues, and this wouldn't actually need
references, you'd just have to register those special references with
the memory manager.

> I think that the issue is too varying and complex to have it
> built-in. I would prefer if Ada provided mechanisms for
> implementation of such stuff at the library level. E.g. user-defined
> access types with primitive referencing, dereferencing, finalization
> operations. Classes of access types etc.

A pure library implementation would make certain optimizations
difficult or impossible: for example, link-time replacement of
tasking-safe counter implementations when there is no tasking, or
avoidance of repeated counter operations on the same object.  It also
requires a lot of mechanics, adding more complexity to the language
than a built-in facility.