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!

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;
X : aliased Foo;
P : Foo_Ptr := X'Access;
begin
X := (F2, 1.0); -- OK
P.all := (F1, 3); -- Error!
end Test;

Is this a compiler bug or intentional language design? Any language lawyers?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 2023-03-22 10:19, Dmitry A. Kazakov wrote:
> I stumbled on a curious fact.
.....
> Is this a compiler bug or intentional language design? Any language
> lawyers?
>

I get
Execution of ./test terminated by unhandled exception
raised CONSTRAINT_ERROR : test.adb:18 discriminant check failed
Call stack traceback locations:
0x402c33 0x402b27 0x7f335b5cfd8e 0x7f335b5cfe3e 0x402b63 0xfffffffffffffffe

bnl@hp-t510:/usr2$ gnatls -v
GNATLS Pro 22.2 (20220605-103)

Linux 64bit - ubuntu 22.04

So it is (also) present on that platform at least

--
/Björn

On 22.03.23 10:19, Dmitry A. Kazakov wrote:
> 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!
>
> 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;
>    X : aliased Foo;
>    P : Foo_Ptr := X'Access;
> begin
>    X := (F2, 1.0);   -- OK
>    P.all := (F1, 3); -- Error!
> end Test;

Some experiments point at the general access type.

type Foo_Ptr is access Foo; -- sans `all`
X : Foo;
P : Foo_Ptr := new Foo;
type Foo1 is new Foo_Ptr (K => F1);
begin
X := (F2, 1.0); -- OK
P.all := (F1, 3); -- _no_ Error!
Foo1 (P).all := (F1, 3);
end Test;

(Doesn't rejection for general access types seem reasonable
if assignment would otherwise require adjusting the storage
layout of a variable, including all access paths to components?
Just guessing.)

On 2023-03-22 15:10, G.B. wrote:

> Some experiments point at the general access type.
>
>    type Foo_Ptr is access Foo; -- sans `all`
>    X : Foo;
>    P : Foo_Ptr := new Foo;
>    type Foo1 is new Foo_Ptr (K => F1);
> begin
>    X := (F2, 1.0);   -- OK
>    P.all := (F1, 3); -- _no_ Error!
>    Foo1 (P).all := (F1, 3);
> end Test;

You get no error because you do not change the discriminant. Change your
code to:

P.all := (F2, 1.0); -- Error!

> (Doesn't rejection for general access types seem reasonable
> if assignment would otherwise require adjusting the storage
> layout of a variable, including all access paths to components?
> Just guessing.)

I guess that an implementation must allocate memory for any value unless
you constraint the discriminants in a subtype. But I am not a language
lawyer to judge.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

I do hope, this answers the question:

3.10(14/3) … The first subtype of a type defined by … an access_to_object_definition is unconstrained if the designated subtype is an .... discriminated subtype; otherwise, it is constrained.
4.8(6/3) If the designated type is composite, then … the created object is constrained by its initial value (even if the designated subtype is unconstrained with defaults).

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. 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!
--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
https://www.adalog.fr https://www.adacontrol.fr

On 2023-03-23 18:53, AdaMagica wrote:
> I do hope, this answers the question:
>
> 3.10(14/3) … The first subtype of a type defined by … an
> access_to_object_definition is unconstrained if the designated
> subtype is an ... discriminated subtype; otherwise, it is
> constrained.

What do you infer from this, relating to Dmitry's original example code
and the error? The "first subtype .. defined" here is the access
subtype, and I don't see how that affects an assignment /via/ this
access subtype to the accessed object.

(It is not clear to me how an access subtype that is constrained differs
from one that is unconstrained. Can someone clarify?)

> 4.8(6/3) If the designated type is composite, then … the created
> object is constrained by its initial value (even if the designated
> subtype is unconstrained with defaults).

That rule applies to objects created by allocators, but the original
example code has no allocators (some later variants do). The object in
question is created by a declaration (which includes the "aliased"
keyword), not by an allocator.

Also, AARM 3.10 contains the following notes on "Wording Changes from
Ada 1995":

26.d/2 {AI95-00363-01} Most unconstrained aliased objects with defaulted
discriminants are no longer constrained by their initial values. [...]

26.k/2 {AI95-00363-01} The rules about aliased objects being constrained
by their initial values now apply only to allocated objects, and thus
have been moved to 4.8, “Allocators”.

This seems to mean that aliased objects created by declarations are
/not/ constrained by the initial value, so it should be possible to
change the discriminant. This seems to be a change from Ada 95 to Ada
2005. I don't see why that change could not be done via an access to the
object.

I added some output to Dmitry's original code, with this result:

X'Constrained = FALSE
P'Constrained = TRUE
P.all'Constrained = TRUE

The first two values of 'Constrained (for X and P) are as expected by
the RM rules, and the third value (for P.all) is consistent with the
error, and seems valid for Ada 95, but the wording change quoted above
suggests that it is wrong for Ada 2005 and later. This leads me to
suspect that GNAT has not been fully updated for this RM change, so it
would be a GNAT bug. Still, the addition of

subtype Foo2_Ptr is Foo_Ptr (K => F2);

to Dmitry's original example provokes this error message:

fuf.adb:16:24: access subtype of general access type not allowed
fuf.adb:16:24: discriminants have defaults

which suggests that at least this part of AI95-00363 has been
implemented, as noted in AARM 3.10:

14.b/2 Reason: {AI95-00363-01} [...] Constraints are not allowed on
general access-to-unconstrained discriminated types if the type has
defaults for its discriminants [...]

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.

On 2023-03-23 19:55, Niklas Holsti wrote:

> 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.

Yes this is substitutability violation. Such cases never go without a
punishment. In this case it is an implementation overhead.

Consider:

procedure Set (Destination : in out Foo; Source : Foo) is
begin
Destination := Source;
end Set;

The compiler cannot implement Set in a natural way, because Destination
might be arbitrarily constrained by the caller. E.g. when the actual for
Destination is P.all. So, the constraint must be passed together with
the actual. A quite burden.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Le 23/03/2023 à 19:55, Niklas Holsti a écrit :
>
>> 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?

I didn't dig in the RM in all details, but I think this comes from the
fact that being constrained (always) is a property of the pointer (more
precisely, its subtype), not of the pointed-at object.

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
https://www.adalog.fr https://www.adacontrol.fr

The rule is question is 4.1(9/3):

If the type of the name in a dereference is some access-to-object type T,
then the dereference denotes a view of an object, the nominal subtype of the
view being the designated subtype of T. If the designated subtype has
unconstrained discriminants, the (actual) subtype of the view is constrained
by the values of the discriminants of the designated object, except when
there is a partial view of the type of the designated subtype that does not
have discriminants, in which case the dereference is not constrained by its
discriminant values.

We have to do that so as otherwise the access value would have to carry a
designation as to whether the object was allocated or not.

-------

This rule was inherited from Ada 83.

IMHO, this rule is stupid. It's even more stupid with the hole for types
that have partial views without discriminants. The *proper* solution is to
get rid of the rarely used and mostly useless access constraints, and then
have no extra restrictions on access values. But that's considered too
incompatible.

Randy.

"J-P. Rosen" <rosen@adalog.fr> wrote in message
news:tvjr7l$1js79$1@dont-email.me...
> Le 23/03/2023 � 19:55, Niklas Holsti a �crit :
> >
> >> 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?
>
> I didn't dig in the RM in all details, but I think this comes from the
> fact that being constrained (always) is a property of the pointer (more
> precisely, its subtype), not of the pointed-at object.
>
> --
> J-P. Rosen
> Adalog
> 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
> https://www.adalog.fr https://www.adacontrol.fr
>