From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: assignment aggregates in controlled types Date: Mon, 24 Feb 2020 17:13:51 -0600 Organization: JSA Research & Innovation Message-ID: References: <7c74a973-e278-427c-bbda-f4c1ebf8fdef@googlegroups.com> Injection-Date: Mon, 24 Feb 2020 23:13:52 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="18825"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader01.eternal-september.org comp.lang.ada:58140 Date: 2020-02-24T17:13:51-06:00 List-Id: wrote in message news:7c74a973-e278-427c-bbda-f4c1ebf8fdef@googlegroups.com... >Does anyone know what, if anything, the language say about the use of >assignment >aggregates during adjust/finalize procedures? If you do something like >this: > >procedure Finalize (Object : in out T) is >begin > Object := (x => 0); >end; > >does not that create a temporary object on the RHS that is assigned (and >adjusted) into the LHS, and then the RHS itself finalized by calling >Finalize, >and then it's finalization procedures all the way down? For types that are >not >required to build-in-place, it's unspecified whether it is (right?), so >presumably >that's a valid behavior? Is such behavior prohibited, expected, undefined, >implementation-defined, or even mentioned in the LRM at all? Controlled types are always required to be built-in-place, but build-in-place never applies to assignment statements (it's for *initialization* of an object). There is a permission to remove the temporary and/or the calls to Finalize and Adjust, but never a mandate. Ergo, if you use such an assignment in Finalize or Adjust, you are possibly making a recursive call. Which obviously isn't going to work. So portable code needs to avoid any sort of full-item assignment in Finalize and Adjust. (Typically, Finalize and Adjust deal only with a handful of components anyway.) It would be possible to define some sort of build-in-place analog for assignment statements, but it hasn't seemed an important enough problem to deal with. Note that build-in-place was originally defined to avoid a semantic problem: it was impossible to portably put an initialized object of a controlled type into a package specification: the Adjust routine would not yet be elaborated, so any attempt to do so would raise Program_Error. There is no workaround to avoid that short of putting the initialization itself into the body (and that would prevent declaring a constant). There's no such problem with assignment; one can always use component-at-a-time assignments as an alternative. I don't recall ever having run into this problem in my programs, but that might be a style issue. Randy.