As I indicated, I agree with your concern. I have created a new issue on the ARG GitHub site:
https://github.com/Ada-Rapporteur-Group/User-Community-Input/issues/85 Please take a look to verify that I have captured your concern. In the future I would encourage you to use the ARG GitHub site instead of ada-comment, as the GitHub site provides a more open place to discuss language issues. You can look at all of the existing issues, and open new ones at: https://github.com/Ada-Rapporteur-Group/User-Community-Input/issues Take care, -Tuck On Wed, Feb 14, 2024 at 6:40 AM Christoph & Ursula Grein < [email protected]> wrote: > Randy and Tuck, > > first of all, I have to apologize for pestering you with this mail. It was > never meant to be sent. I wrote it with the intention to send it and > collected the RM paragraphs, but the more I did I saw that I wasn't ready. > So I wanted to quit and pressed the wrong button. > > I thought about immediately sending a second mail saying "please ignore" - > but then: what I writ I writ! > > So I made a long pause before I now come back to this. Apology again for > answering so late. And thank you for your patience. > > *Randy: How do YOU want this to work?? Explain your answer.* > > In effect, I had expected something like what GNAT did, a kind of > aggregate, but without the discriminants that do not occur in an aggregate. > So I tried to understand what the RM has to say... (not a moderate task) > > I've read the complete AIs about the new Image. (There is a remark that > perhaps later a matching Value could be defined. I guess this idea has been > dropped. How could this be done with Image having components not available > in the aggregate.) > > I read RM 4.10(7/5) that the parent image should be given, which GNAT did > not do (CE 2021; perhaps this has changed meanwhile) because it used the > actual discriminant names. [This is not a bug report.] > > I see there are conflicting aims: Using extension aggregates when > Put_Image is defined for an ancestor (which might have different > discriminants), else using the actual names. I gather that Tuck feels some > sympathy for using actual names! > > So in effect the current solution for untagged records looks OK (replacing > discrimininants instead of inheriting them seems like nonsense). > > *What I do not understand is RM 4.10(17/5, 18/5) talking about the default > implementation of T'Write. T'Write does not include discriminants except > when they have defaults, which they do not have here* (yet GNAT outputs > them)*. An image without discriminants seems like utter nonsense to me *- > which is what GNAT creates for Image with tagged derived types under > certain conditions > *! Is this really the intention? See below: * > > ----------------------- > > with Ada.Text_IO; > use Ada.Text_IO; > > with Interfaces; > use Interfaces; > > procedure Sequence is > > type T0 (D0: Integer_8) is tagged record > K0: Integer_8; > end record; > > type T1 is new T0 (D0 => -1) with record > K1: Integer_8; > end record; > > procedure P0 is > -- D0 K0 > X: T0 := ( 1, -1); > begin > Put_Line ("P0"); > Put_Line ("=="); > Put_Line (X'Image); > New_Line; > end P0; > > procedure P1 is > -- D0 K0 K1 > X: T1 := (-1, -2, 8); -- D0 must be -1 > begin > Put_Line ("P1"); > Put_Line ("=="); > Put_Line (X'Image); > New_Line; > end P1; > > begin > > P0; > P1; > > end Sequence; > ----------------------- > > P0 > == > > (D0 => 1, > K0 => -1) > > P1 > == > > (K0 => -2, > K1 => 8) > >
