comp.lang.ada
 help / color / mirror / Atom feed
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Subject: Re: Assignment access type with discriminants
Date: Thu, 23 Mar 2023 20:09:21 +0200	[thread overview]
Message-ID: <k83iuhF8ubmU1@mid.individual.net> (raw)
In-Reply-To: <1775482e-fd70-4af8-b25d-c2a9c2892b05n@googlegroups.com>

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

  reply	other threads:[~2023-03-23 18:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-22  9:19 Assignment access type with discriminants Dmitry A. Kazakov
2023-03-22  9:31 ` Björn Lundin
2023-03-22 14:10 ` G.B.
2023-03-23 11:51   ` Dmitry A. Kazakov
2023-03-23 16:53     ` AdaMagica
2023-03-23 18:09       ` Niklas Holsti [this message]
2023-03-23 17:04 ` J-P. Rosen
2023-03-23 18:55   ` Niklas Holsti
2023-03-23 19:53     ` Dmitry A. Kazakov
2023-03-24  9:41     ` J-P. Rosen
2023-03-25  8:51       ` Randy Brukardt
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox