Re: A hole in Ada type safety

[anon@att.net]

Your two programs has pointed out a puzzle in the RM-2005.  And that is 
does the definition of the standard Generic package Unchecked_Conversion 
violate the RM (6.5/(5.5/2). 

      generic
         type Source(<>) is limited private;
         type Target(<>) is limited private;
      function Ada.Unchecked_Conversion(S : Source) return Target;
      pragma Convention(Intrinsic, Ada.Unchecked_Conversion);
      pragma Pure(Ada.Unchecked_Conversion);


And when you compile the RM Ada 95 specification and body version of 
the Unchecked_Conversion using Ada 2005 compiler you get the following 
errors:

   (Ada 2005) cannot copy object of a limited type (RM-2005 6.5(5.5/2))
   return by reference not permitted in Ada 2005
   consider switching to return of access type

But that suggest the RM standard generic Unchecked_Conversion is obsolete 
in its current version or is in error. And yes, I know that mostly the 
compiler emulates the Unchecked_Conversion body, but that not always an 
option.

Now, since one reason the extended return statement was created was to 
handle "Limited Private" type the simple and return aggregate statements 
are out.

And, using a simple design of the extended return statement causes semantic 
error in Ada 95/2005 because any reference to an unconstrained Target is 
not valid. Such as:

      return Result : Target do    -- not valid, must be initialized
                                   -- in this form (Discriminant)
          Result := Target ( Object_Access.all ) ;
        end return ;


So, how does one use this extended return statement to return a 
"Unconstrained Discriminated Limited Private" object for this type of 
generic function?  Or is the Unchecked_Conversion generic function a 
violation of the RM 2005 rules?




In <87pqntscwj.fsf@mid.deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes:
>* Dmitry A. Kazakov:
>
>> Then a built-in access-to-component type might be a better solution. It
>> would eliminate a need for components to be aliased. Since the offset is
>> statically known (or a function that calculates it is), it need not to be
>> kept anywhere.
>
>You'd still have the safety hazard with the reference to the outer
>record.  There are is some impact on encapsulation which has to be
>considered.  And it's not going to help with the original problem (a
>safer replacement for discriminants with defaults).
>
>> OK, but you need to create the first reference somehow.
>
>Uhm, I had imagined you'd use an allocator for that.  The whole thing
>is meant to be a bit similar to access values.
>
>>>> IMO weak references are quite useless if do not support notifications (when
>>>> the last strong reference is removed). I.e. you need a list of weak
>>>> reference holders.
>>> 
>>> I think they are supposed to be used for parent pointers in trees, for
>>> instance, to avoid the cycle issue.  Not so much for finalization.
>>
>> I rather use: parent-->child is a plain pointer, child-->parent is a
>> strong reference.
>
>Dereferencing a weak pointer incurs a run-time check and operations on
>the counters (if reference counting is used), and the parent pointer
>is only needed for some traversal operations, so weak pointers upwards
>seem the way to go.
>
>> The most interesting cases for weak references are in the first line
>> finalization notification. E.g. cached objects.
>
>You would get that with controlled types.
>
>I don't think weak references work for caches if you have reference
>counts and precise finalization because the last reference to the
>cached object goes away too soon.  There are different types of
>references (sometimes called "weak", too) which are cleared by the
>memory manager if it cannot satisfy an allocation request, but this
>raises awkward concurrency issues, and this wouldn't actually need
>references, you'd just have to register those special references with
>the memory manager.
>
>> I think that the issue is too varying and complex to have it
>> built-in. I would prefer if Ada provided mechanisms for
>> implementation of such stuff at the library level. E.g. user-defined
>> access types with primitive referencing, dereferencing, finalization
>> operations. Classes of access types etc.
>
>A pure library implementation would make certain optimizations
>difficult or impossible: for example, link-time replacement of
>tasking-safe counter implementations when there is no tasking, or
>avoidance of repeated counter operations on the same object.  It also
>requires a lot of mechanics, adding more complexity to the language
>than a built-in facility.