Re: Visibility of Indexing aspects

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2018-08-06 23:46, Randy Brukardt wrote:
> "Dan'l Miller" <optikos@verizon.net> wrote in message
> news:cc25c794-5986-4f6e-9d5e-0ec20a4f47d0@googlegroups.com...
> ...
>> Ummmmmmmmm, what is so incredibly "expensive" about Element =>
>> Self.Data(Index)'Access in OP?
> 
> Nothing is expensive about *that*, but it's also very unsafe by itself (this
> either prevents a container from ever reusuing memory, or essentially
> requires being OK with dangling pointers and the erroneousness that they
> cause).
> 
> Our requirement was that the user-defined dereference mechanism needs to be
> safe (at least possible to be safe), and that requires the container to be
> able to find out when the dereference ceases to exist. At that point, the
> container can free the underlying memory if need be. (For an extreme
> example, consider a persistent container, where the object only should exist
> in memory so long as it is being used there.) The design that we came up
> with for Ada 2012 uses finalization for this notification; we looked at
> other mechanisms, but they would have had similar overhead.
> 
> The Ada containers use the finalization to clear the tampering check (which
> prevents deleting of elements while the dereference exists); other uses are
> possible, of course.
> 
> Without these sorts of checks, Ada containers would be no more safe than C
> code. In particular, Ada programmers do not expect checked indexing to be
> unsafe, so syntax of C(I) being unsafe would be a particular surprise.

Right, exposing references, e.g. having named types of and explicit 
objects of, is always either unsafe or both unsafe and inefficient. 
There is no satisfactory solution on that path.

No way to decompose A(I):=X literally. After fixing Ada type system we 
should better try Update(A,I,X).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de