Re: IR 2048

This example is very questionable, if not illegal.
Clause 3.3.2 Allocation and deallocation of objects
states in a Note:

"If an access value is copied to a second variable and is then 
deallocated, the second variable is not set to null and thus references
invalid storage."

Its a note because the behavior (behaviour for Peter)  is a consequence 
of the semantics of deallocate.

In my opinion, the example is erroneous, so I'm not too concerned about the
impurity of the function.

Ajayharsh Varikat wrote:

>Gentlemen,
>
>I have a minor issue with item 4 from this IR. This is the issue
>about pure functions returning access types. The proposed resolution
>is to disallow access type return values in pure functions.
>
>Even with this restriction, it is possible to write a pure function
>that returns different values.
>
>Consider the following:
>
>      pure function bad return integer is
>          variable a, b : intp;
>      begin
>          a := new integer;
>          b := a;
>          deallocate ( a );
>          a := new integer;
>          if a = b then
>              return 1;
>          else
>              return 0;
>          end if;
>      end;
>
>Depending on the way allocation is done, this function may return different
>values on different implementations. In fact, with certain memory
>management optimizations, this functions can even return different values
>at different times on the same implementation.
>
>However, I think this is a far-fetched situation, and is unlikely to happen
>in any meaningful function. Hence I believe the current resolution would
>be sufficient. The alternative of not allowing allocators within pure
>functions may be too severe.
>
>Just wanted to point this out, in case it triggers other trains of thought.
>
>Regards,
>
>-ajay
>  
>