From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	ip-172-31-65-14.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-3.2 required=3.0 tests=BAYES_00,NICE_REPLY_A,
	T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
Path: eternal-september.org!feeder.eternal-september.org!news.szaf.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Assignment access type with discriminants
Date: Thu, 23 Mar 2023 20:55:48 +0200
Organization: Tidorum Ltd
Message-ID: <k83llkF8ubmU2@mid.individual.net>
References: <tveh6u$ihpu$1@dont-email.me> <tvi0qt$17pev$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net hn1q6ZMj8+vJEM7MlR2evAKW6m5Qp8QvnxDoD/jNIbGLwTj9tU
Cancel-Lock: sha1:mAKwXX5gkVEFpPHzt10jBXRuRCA=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:102.0)
 Gecko/20100101 Thunderbird/102.6.1
Content-Language: en-US
In-Reply-To: <tvi0qt$17pev$1@dont-email.me>
Xref: feeder.eternal-september.org comp.lang.ada:65015
List-Id: <comp.lang.ada>

On 2023-03-23 19:04, J-P. Rosen wrote:
> Le 22/03/2023 à 10:19, Dmitry A. Kazakov a écrit :
>> I stumbled on a curious fact.
>>
>> The value of an object with a discriminant can be changed to a value 
>> with a different discriminant if the type's discriminants are defaulted.
>>
>> Right?
>>
>> Wrong! Not through an access type!
>>
> (...)
>> Is this a compiler bug or intentional language design? Any language 
>> lawyers?
>>
> An access value is always constrained by its initial value; this is 
> necessary because of constrained access subtypes.


But constrained access subtypes are not allowed for general access types 
like Foo_Ptr in the example.


> Here is a slightly 
> modified version of your example:
> 
> procedure Test is
>     type F is (F1, F2, F3);
> 
>     type Foo (K : F := F1) is record
>        case K is
>           when F1 =>
>              X1 : Integer;
>           when F2 =>
>              X2 : Float;
>           when F3 =>
>              X3 : String (1..2);
>        end case;
>     end record;
>     type Foo_Ptr is access all Foo;
>     type Foo_Ptr2 is access Foo;
>     X : aliased Foo;
>     P : Foo_Ptr := X'Access;
>     PF2: Foo_PTR2 (F2);
> begin
>     X := (F2, 1.0);   -- OK
>     PF2 := new Foo (F2);
>     P := PF2.all'Access;
>     P.all := (F1, 3); -- Error!
> end Test;
> 
> Without this rule, PF2.all would now designate a value whose 
> discriminant is F1!


This error is understandable and valid, because now P.all is PF2.all 
which is an allocated object and therefore constrained by its initial 
value with K = F2.

But why should the same apply when P designates X, which is 
unconstrained? Is it just an optimization (in the RM) so that a general 
access value does not have to carry around a flag showing whether its 
designated object is constrained or unconstrained?

Perhaps it would be better to make the assignment P := PF2.all'Access 
illegal, because it in effect converts a constrained access value (PF2) 
to an unconstrained access subtype (P), and so in some sense violates 
the prohibition of constrained subtypes of general access types.