Re: Question regarding example code in AI12-0140

[Brad Moore <brad.moore@shaw.ca>]

On 14-10-31 01:40 PM, AdaMagica wrote:
> Am Donnerstag, 30. Oktober 2014 16:59:31 UTC+1 schrieb Mark Lorenzen:
>> In AI-0140 the following example code is given:
>>
>> with Ada.Unchecked_Deallocation;
>>
>> package UNC is
>>
>>     type My_String (<>) is limited private;
>>     type My_String_Access is access My_String;
>> private
>>     type My_String is new String;
>>     procedure Free is new
>>       Ada.Unchecked_Deallocation (My_String, My_String_Access);
>>
>> end UNC;
>>
>> The AI discusses if this is legal Ada or not.
>
> Hu - I've got severe problems to understand the AI. It says:
> "The full view of My_String is constrained, while My_String_Access designates the partial view of My_String, which is unconstrained."
>
> But since when is type String constrained? So why is the full view of My_String constrained?
>
> Am I blind?
>

The AI needs some cleanup, and the sentence in the question that says;

"The full view of My_String is constrained, while My_String_Access 
designates the partial view of My_String, which is unconstrained. "

is misleading and incorrect, since as you you point out type My_String 
is an unconstrained subtype as defined in RM 3.2(9).

The original issue was not really about the My_String type. It was about 
the My_String_Access type. It's declaration in the public part of the 
package is that of an access type that designates a type that has 
unknown discriminants. Any subtype of a type with unknown discriminants 
is an unconstrained and indefinite subtype. see RM 3.7 (26)

However in the private part of the package where the instantiation 
occurs and the full view of My_String can be seen, we find out that 
My_String has no discriminants, which is not the same as having unknown 
discriminants.

In the instantiation of Unchecked_Deallocation, the My_String generic 
formal has no discriminants. The other generic formal, Name has has to 
designate a type that statically matches the Object formal, yet at first 
glance these do not appear to match.

RM 4.9.1 (1.2/2) A constraint statically matches another constraint if:
both are static and have equal corresponding bounds or discriminant values;

In the Appendix of the AI however, Tucker explains that for statically 
matching, it is the properties of the designated type that matter, not 
the properties of the access type that designates them. "The properties 
of the designated type change as you learn more about the designated 
type." He further points out that the access types in question are 
exactly the *same* type, so they should match each other statically. 
That is, both the access type declared in the public part of the package 
and the view of the access type in the private part designate the 
My_String type.

So the effect of this AI would likely just be a clarification in the 
wording of the RM, but most compilers otherwise would not need any 
changes. In Randy's case he would need to make a change to his compiler, 
because he has a compiler bug.

Brad