Re: Not null feature with anonymous and named access types

["Alex R. Mosteo" <devnull@mailinator.com>]

Anh Vo wrote:
 
> Dmitry A. Kazakov wrote:
>> On 14 Jun 2006 08:37:13 -0700, Anh Vo wrote:
>>
>> via *this* pointer, which does not mean that it cannot be reclaimed at
>> all. Consider trivial stack allocated aliased variable.
> 
> I am afraid I do not understand "this* pointer means. What I was
> talking about not null access object using heap memory, not aliased
> variable at all. See my code snipet from my original post.

I think he's refering to something like (I certainly was):

declare
   type AI is access all Integer;
   type NNAI is not null access all Integer;

   NNI : NNAI := new Integer'(6);
   I   : AI   := AI (NNI);  

begin
   -- You can't free NNI but you can free I. Of course, then NNI is
   -- dangling and can't be nullified, but it could get a new proper
   -- value. This would be fine if done in some body for whatever
   -- reasons.
end;

> 
>> No, you just don't use not-null pointers where deallocation is possible /
>> necessary. That's the very idea of not-null pointers.
> 
> I weight memory leak more important than convenient way of using null
> excluded pointer. I am fine with not null pointer pointing to an
> aliased object. In this case, attemptingp to deallocate the pointer is
> clearly a language violation.
> 
>> For example, consider an implementation of a container. Its public
>> operation Get_Element could return a not-null pointer to the element,
>> ensuring two things: 1. the client will never get a null (so no need to
>> check it) 2. the client will never be able to deallocate the element
>> through the pointer returned. Internally the implementation may allocate
>> and deallocate elements using other pointers. So another operation
>> Remove_Element_By_Index would do it.
>>
>> [It is still unsafe, as any aliasing is, yet definitely better than
>> nullable pointers.]
> 
> There is no disagreement here.
> 
> AV