Overriding Default_Component_Value in derived array type

Overriding Default_Component_Value in derived array type

[Niklas Holsti]

I'm seeing behaviour that looks strange to me when I derive an array 
type from another and use a Default_Component_Value aspect that tries to 
override the corresponding aspect of the parent type. The parent's 
default value is used also for the derived type, that is, the aspect 
definition for the derived type has no effect, it seems.

This is on macOS Mojave (10.14.6), GNAT Community 2019 (20190517-83).

An example:

       type Number is range 1 .. 15;

       type Arr_2 is array (3 .. 5) of Number
       with Default_Component_Value => 2;

       type Arr_6 is new Arr_2
       with Default_Component_Value => 6;

       A2 : Arr_2;
       A6 : Arr_6;

Printing out the default values of A2 and A6 I get 2's for both. I 
expected 2's for A2 and 6's for A6, as I read the RM.

Overriding Default_Value for a derived integer type works as expected, 
as does overriding a Default_Value for the component type with a 
Default_Component_Value for the array type.

For the array type derivation, if the parent array type has no 
Default_Component_Value then the Default_Component_Value for the derived 
type is effective. That is, in the above example, if I remove the 
Default_Component_Value from Arr_2, then A2 contains garbage as 
expected, and A6 contains sixes.

Bug or feature?

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Overriding Default_Component_Value in derived array type

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:hg8rdgFpoa2U1@mid.individual.net...
> I'm seeing behaviour that looks strange to me when I derive an array type 
> from another and use a Default_Component_Value aspect that tries to 
> override the corresponding aspect of the parent type. The parent's default 
> value is used also for the derived type, that is, the aspect definition 
> for the derived type has no effect, it seems.
>
> This is on macOS Mojave (10.14.6), GNAT Community 2019 (20190517-83).
>
> An example:
>
>       type Number is range 1 .. 15;
>
>       type Arr_2 is array (3 .. 5) of Number
>       with Default_Component_Value => 2;
>
>       type Arr_6 is new Arr_2
>       with Default_Component_Value => 6;

This is usually illegal by 13.1(10), so it is very rarely done. (If there 
are any subprograms for Arr_2, then Arr_6 is illegal.) We're talking about 
repealing 13.1(10), which will make it more necessary for compilers to get 
this sort of stuff right.
...
> Bug or feature?

Surely bug. If one didn't give the Default_Component_Value aspect, then of 
course the value would inherit. But be careful that you're not using an 
inherited routine (that would of course use the value for it's own type).

BTW, my understanding is that AdaCore is reworking Default_Value and 
Default_Component_Value because some silly person (that would be me) wrote a 
bunch of ACATS tests for those aspects. (That's why the request came in to 
repeal 13.1(10)). The next version is likely to be better.

                       Randy.


 

Re: Overriding Default_Component_Value in derived array type

[Niklas Holsti]

On 2020-04-22 0:32, Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
> news:hg8rdgFpoa2U1@mid.individual.net...
>> I'm seeing behaviour that looks strange to me when I derive an array type
>> from another and use a Default_Component_Value aspect that tries to
>> override the corresponding aspect of the parent type. The parent's default
>> value is used also for the derived type, that is, the aspect definition
>> for the derived type has no effect, it seems.
>>
>> This is on macOS Mojave (10.14.6), GNAT Community 2019 (20190517-83).
>>
>> An example:
>>
>>        type Number is range 1 .. 15;
>>
>>        type Arr_2 is array (3 .. 5) of Number
>>        with Default_Component_Value => 2;
>>
>>        type Arr_6 is new Arr_2
>>        with Default_Component_Value => 6;
> 
> This is usually illegal by 13.1(10), so it is very rarely done. (If there
> are any subprograms for Arr_2, then Arr_6 is illegal.)

Yes. (Just for the record, I wasn't doing this for a real application,
but to support some discussions I was having about initialization in
various languages -- C, Ada, Java.)

> We're talking about repealing 13.1(10), which will make it more
> necessary for compilers to get this sort of stuff right.
Oh. Sounds complex, if an inherited primitive operation should use the 
default component value of its actual argument type, while sharing code 
with other parent and derived types ... perhaps a hidden parameter would 
be needed?

>> Bug or feature?
> 
> Surely bug.

Thanks. I'll consider submitting a bug report to AdaCore.

> If one didn't give the Default_Component_Value aspect, then of
> course the value would inherit.

Yes, and I saw that happen in another test. Moreover, if I remove the 
parent type's Default_Component_Value aspect, then the aspect in the 
derivation takes effect.

> But be careful that you're not using an inherited routine (that would
> of course use the value for it's own type).
Would that happen (inherited routine using the value for its own type) 
even if you repeal 13.1(10)?

> BTW, my understanding is that AdaCore is reworking Default_Value and
> Default_Component_Value because some silly person (that would be me) wrote a
> bunch of ACATS tests for those aspects. (That's why the request came in to
> repeal 13.1(10)). The next version is likely to be better.

So AdaCore already know about this bug, and perhaps others?

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Overriding Default_Component_Value in derived array type

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:hgh2svFi1oqU1@mid.individual.net...
...
>> But be careful that you're not using an inherited routine (that would
>> of course use the value for it's own type).
> Would that happen (inherited routine using the value for its own type) 
> even if you repeal 13.1(10)?

Yes, of course. We're not going to start requiring dispatching for untagged 
types. Anything else would be a nasty distributed overhead.

                Randy.