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!2.eu.feeder.erje.net!feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Assignment access type with discriminants Date: Thu, 23 Mar 2023 20:09:21 +0200 Organization: Tidorum Ltd Message-ID: References: <1775482e-fd70-4af8-b25d-c2a9c2892b05n@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net l1jQtT0ilWjm1UQomRtkIgqTowwV9U+IInrTf8usml9D4oPVAn Cancel-Lock: sha1:BiJDJlnrrPCq1TuhnPouKflxMFA= 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: <1775482e-fd70-4af8-b25d-c2a9c2892b05n@googlegroups.com> Xref: feeder.eternal-september.org comp.lang.ada:65014 List-Id: 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 [...]