Re: On absurdity of collections 7.6.1 (11.1/3)

[Simon Wright <simon@pushface.org>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 2021-09-29 13:05, Simon Wright wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>>        type Item_Ptr is access all Item;
>>>        function New_Item
>>>                 (  Pool : in out Root_Storage_Pool'Class;
>>>                    Text : String
>>>                 )  return Item_Ptr;
>> What I don't see is how you can implement this, never mind any other
>> problems.
>
> A naive, but wrong due to 7.6.1 (11.1/3) nonsense, implementation would be:
>
>      function New_Item
>               (  Pool : in out Root_Storage_Pool'Class;
>                  Text : String
>               )  return Item_Ptr is
>         type Ptr is access Item;
>         for Ptr'Storage_Pool use Pool;
>         Object : Ptr := new Item (Text'Length);
>      begin
>         Object.Text := Text;
>         return Object.all'Unchecked_Access;
>      end New_Item;

OK, that code compiles.

What you'd need to happen when the returned Item_Ptr is freed would be
for the mechanism of the actual pool to be invoked. But Item_Ptr was
declared without any pool specified, so uses the default, and when the
returned Item_Ptr is freed it uses the default pool's mechanism.

But of course what actually happens with this code is that the returned
Item_Ptr is left dangling; my test

   with P;
   with System.Pool_Local;   -- GNAT special
   with Ada.Text_IO; use Ada.Text_IO;
   procedure Test is
      use P;
      Pool : System.Pool_Local.Unbounded_Reclaim_Pool;
      Ptr : Item_Ptr := New_Item (Pool, "hello");
   begin
      Put_Line (Ptr.Text);
      Free (Ptr);
   end Test;

manages flukily to print "hello" before crashing at the Free (Ptr).

I don't see how what you want can be achieved without every access type
containing a reference to the pool the object was allocated from.