Re: New aggregates with Ada 2022.

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2022-06-22 01:28, Randy Brukardt wrote:

> 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.

Just like aggregates now, record types *must* have interface. Your 
"circus" will inevitable face this same problem again - how to define 
record members of a private type implemented by a built-in record type 
in the full view? The language must universally handle all sorts of 
interfaces.

> 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]).

I would first answer basic questions, which interfaces have array vs 
user-defined aggregate/index. How are they related to each other etc.

> 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??

Well, I can give a useful example straight away. A string has two array 
interfaces, the encoding and the character view. The former must be a 
built-in array.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de