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=-1.9 required=3.0 tests=BAYES_00,T_SCC_BODY_TEXT_LINE, XPRIO autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: New aggregates with Ada 2022. Date: Tue, 21 Jun 2022 18:28:17 -0500 Organization: A noiseless patient Spider Message-ID: References: Injection-Date: Tue, 21 Jun 2022 23:28:18 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="3943c1bd97a1959445a9f71f871aed17"; logging-data="31174"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18wvbgUfP7wH00K1MkiqtoNasm5zXWA8IA=" Cancel-Lock: sha1:FtIi9x9xPOJ/4TqlkJdJv8EO1lk= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 X-RFC2646: Format=Flowed; Response X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-Priority: 3 X-MSMail-Priority: Normal Xref: reader02.eternal-september.org comp.lang.ada:64008 List-Id: "Dmitry A. Kazakov" wrote in message news:t8qrmo$p79$1@gioia.aioe.org... > On 2022-06-20 23:47, Randy Brukardt wrote: > >> The reason for this is obvious in your question: it is ambiguous if an >> aggregate is an array aggregate or a container aggregate wherever the >> full >> type is visible, and that is not worth making work (any choice would be a >> surprise in some contexts). > > I don't agree that making the language regular does not worth work. There's always a way, but is it worth the implementation effort? And would it be confusing to use? > The choice is obviously inconsistent with handling both existing cases: > > 1. Built-in operations -> hiding: > > type T is private; > function "+" (Left, Right : T) return T; -- Perfectly legal > private > type T is range 1..100; This case is not worth the effort, IMHO. (Of course, it is in the language now, so we're stuck with it.) If I was running the circus, private types could only be completed with a record type. 99% of the time, that's what you want. And the other 1% of the time, you will eventually end up changing it into a record for one reason or the other. So why pollute the language rules for something primarily useful in ACATS tests? > 2. Primitive operations -> overriding. > > What's good for the goose is good for the gander? Nope. Here is a totally > new way of handling an operation! The problem here is illustrated by the OP, who seemed to expect to get the container aggregate when the full view is visible. We looked at making the container aggregate invisible and allowing the array aggregate in the full view, but it would be something new (the contents of aggregates don't depend on visibility in Ada 2012), and it seems useless (see my answer to [1]). That is, the OPs construct is primarily useful in small examples; it's not a real world thing you would want to do. (There ALWAYS is some other data that you need to go along with an array: a length, a validity flag, etc.) So why make implementers spend a lot of effort implementing it?? Randy.