Re: Smart pointers and delegation

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:olrqum$1t4b$1@gioia.aioe.org...
> On 2017-08-02 01:06, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:olplb6$jq0$1@gioia.aioe.org...
>>> I would like to discuss delegation proposal as a replacement for crude,
>>> inside out Implicit_Dereference aspect.
>>
>> There never are "replacements", as existing Ada code has to work.
>
> It is not replacement in that sense. Replacement here applies to the "use 
> case", i.e. creating subtypes. Implicit dereferencing effectively makes 
> pointer a "subtype" of the target type.

As I noted at the end of my message, your proposal does not replace the "use 
case" for Implicit_Dereference. So this isn't true.

>> And as usual, you didn't explain the problem that you're trying to solve.
>
> The problem is subtyping and automated creation of wrappers to implement 
> "trivial" operations. The method is delegation. Examples are presented.

I think you need to concentrate on describing that problem rather than any 
particular solution to solve it. It doesn't seem like a problem that is 
really solveable in the general case. (Certainly if you want to make some 
sort of proposal; not so much if you are just making talk here.)

...

>> Implicit_Dereference very much matches the Ada model of "hooks" into
>> language-defined operations (much like Adjust and Finalize allow
>> user-defined operations to be associated with an assignment, rather than
>> replacing it).
>
> ? Not even close. Adjust and Finalize are primitive operations, which was 
> a horrific design choice, but nevertheless. Implicit dereference is not an 
> operation, not even a body.

In the intended use, Implicit_Dereference is always combined with a 
controlled type, which provides the actual hooks. As I noted yesterday, the 
original idea was specifically for explicit hooks (as part of the storage 
pool mechanism, similar to Adjust and Finalize), but that got replaced when 
it was pointed out that one could already write the needed support using an 
access discriminant and associated controlled type. That got rid of the need 
to define new mechanisms and deal with the inevitable corner cases. The only 
problem with that was that it was unspeakably ugly, so Implicit_Dereference 
was created to get rid of that without adding any real new semantics.

Any other use of Implicit_Dereference is purely accidental; no other use 
provides anything that can't be written directly in Ada 95.

>> The main intended use of this feature was to manage the lifetime of 
>> accessed
>> entities, such as a persistent store, without requiring copies of the
>> contained data (which might be large).
>
> Copies are very essential in many cases, e.g. an external reference to a 
> database table row etc. It is up to the programmer to define the 
> semantics.

If you want (or don't care about copies) copies, normal primitive functions 
work great. See, for instance, function Element in the various containers 
packages. The access discriminant/controlled type/Implicit_Dereference 
mechanism is intended for those cases where a copy is not usable (either 
because of semantics or because of execution cost).

>> Your proposal doesn't meet this particular need, because there is no way 
>> to
>> tell when the program is finished with a function result.
>
> I don't understand what you mean. The proposal considers exclusively how 
> to generate bodies of normal primitive operations. All current rules apply 
> to them, no any new rules needed.

That's the problem: the Implicit_Dereference mechanism is intended for the 
rare cases where "normal primitive operations" don't work (because they 
imply copies for function results). If "normal primitive operations" work, 
you don't need (and shouldn't use) any special mechanism.

From your description, you're trying to solve an altogether different 
problem. That's fine, of course, but just don't confuse that with the rather 
low-level problem that Implicit_Dereference was actually trying to solve.

                                    Randy.