From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Aggregate with derived types.
Date: Sat, 16 Sep 2023 01:39:57 -0500 [thread overview]
Message-ID: <ue3ij6$3m5td$1@dont-email.me> (raw)
In-Reply-To: udvooj$2oveh$1@dont-email.me
"Blady" <p.p11@orange.fr> wrote in message
news:udvooj$2oveh$1@dont-email.me...
...
> I wonder why the float list aggregate isn't inferred by the compiler and
> need some help with a qualification.
The language rule is that the ancestor_part of an extension aggregate is
expected to be of "any tagged type" (see 4.3.2(4/2)). An aggregate needs to
have a single specific type, and "any tagged type" is not that.
The reason that the ancestor is "any tagged type" is that the type of the
ancestor determines the extension components needed along with other
legality rules. One could imagine a language where all of these things are
decided simulateously, but people worried that the complexity would make it
difficult/impossible to implement. So aggregates are essentially black boxes
whose type has to be determinable from the outside, and similar rules exist
for parts inside the aggregate.
Randy.
prev parent reply other threads:[~2023-09-16 6:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-14 14:02 Aggregate with derived types Blady
2023-09-14 15:31 ` Jeffrey R.Carter
2023-09-14 20:00 ` Blady
2023-09-14 21:37 ` Jeffrey R.Carter
2023-09-15 7:27 ` Blady
2023-09-16 6:39 ` Randy Brukardt [this message]
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox