Re: How to declare a generic formal type "covered" by another?

[Natasha Kerensikova <lithiumcat@instinctive.eu>]

Hello,

On 2014-05-01, J-P. Rosen <rosen@adalog.fr> wrote:
> Le 01/05/2014 08:54, Natasha Kerensikova a écrit :
>> So S would have to be a concrete constrained type, but looking at the
>> alternatives for "formal_type_definition", I can't see anything that
>> covers both S being a constrained version of T, and S being a concrete
>> tagged type belonging to class-wide T.
>> 
>> Is it possible, or am I hitting a limit of Ada generics?
>
> 1) There is nothing here that requires T to be tagged

Indeed, and I don't want to restrict T to tagged types.

The examples I had in mind are:
  - T is Stream_Element_Array, S is Stream_Element_Array (1 .. 4096)
  - T is Root_Stream_Type'Class, S is a concrete type derived from it

> 2) You can say that S must be derived from T:
>     type S is new T; (non tagged type)
>     type S is new T with private; (tagged type)

It looks like I can't cover both cases in a single declaration, can I?

> 3) There is no way to say that S must be constrained, because being
> constrained is a matter of subtype, and only types matter for generics.

Well maybe the problem here is my limited vocabulary. I used the word
"constrained" there only to mean "Something := new S" or "Variable : S;"
are both valid, i.e. objects of that type can be created without
further information. There must be some way to express that in generics.

> The best way to constrain an allocator is by providing an initial value,
> that you could pass as a parameter to Allocate f.e.

That's the solution I have been running with, but yeasterday I hit a
problem with T being Stream_Element_Array and S being
Stream_Element_Array (1 .. 2**29): the intermediate copy and the
allocator result don't fit both in memory, and the program is OOM
killed.

The only solution I found where a limited discriminated record to hold
the Stream_Element_Array, but that's an invasive changed, and somehow
having the allocator run before filling its contents, which means either
exposing the internal access type (so that a client function can call
the allocator and return the access), or providing a generic function
like in the OP (or some other solution I'm unable to come up with).



Thanks for your help,
Natasha