Re: Incompatible types for array conversion

["Randy Brukardt" <randy@rrsoftware.com>]

"Simon Wright" <simon@pushface.org> wrote in message 
news:ly1tg0jrtm.fsf@pushface.org...
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>
>> On 15-07-22 10:13 , Simon Wright wrote:
>>> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>>>
>>>> The conversion is rejected because of the conversion condition in RM
>>>> 4.6 (24.5/2): "The component subtypes shall statically match". The
>>>> component (sub)types are Real and Length, which are different types,
>>>> although Length is derived from Real. If you change the declaration
>>>> of Length to be
>>>>
>>>>     subtype Length is Real;
>>>>
>>>> the conversion becomes legal.
>>>
>>> I tried
>>>
>>>     generic
>>>        dim: positive;
>>>        type Real is digits <>;
>>>     package Vectors is
>>>        type Vector is array (1..dim) of Real'Base;
>>>
>>> but it still failed. (GPL 2015, FSF 5.1.0)
>>
>> Did you expect it to work? Real'Base gets rid of any constraints on
>> Real, but AIUI does not get rid of the type derivation; if "type
>> Length is new Real", Length'Base is not the same as Real'Base -- the
>> "new" makes them different.
>
> Well, who knows what 'statically match' means! (outside the ARG,
> anyway). I thought it was worth a try.

It's clearly ;-) explained in ARM 4.9.1. Short summary: it's the same type 
with the same constraint. We use statically match simply so that things that 
are "obviously" the same are treated as such:

    subtype S1 is Int range 1 .. 10;
    subtype S2 is Int range 1 .. 10;

S1 and S2 statically match (as one would hope). But if someone declared 
separate types in Ada (as in "new"), they're really different, and then they 
can never statically match (because they don't match in any way).

Some other parts of type conversions use "convertible", which would allow 
such conversions. I think the rules for array components are too strict, but 
simply using "convertible" doesn't work for various obscure reasons, and 
coming up with a concept just for this case isn't worth it. (We looked at 
this as one of the solutions for AI12-0037-1, but in the end we just changed 
the declarations of the types instead.)

                                  Randy.