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 [...]
next prev parent 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