Re: formal array types and default values

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

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:fb3iqsFnjd7U1@mid.individual.net...
...
>    generic
>
>       type T is private;
>
>       Null_Value : in T;
>
>    package Foo is
>
>       type Vector is array (Positive range <>) of T
>          with Default_Component_Value => Null_Value;
>
>    end Foo;
>
> Following the current rules, GNAT rejects this because Null_Value is not 
> (always) a scalar.
>
> If the generic formal type T is changed to "type T is range <>", GNAT 
> accepts the generic package declaration, but accepts an instantiation only 
> if Null_Value is given a static expression (this is GNAT GPL 2012 on Mac).

Correct. And you can't do it at all in the body (as a formal object will not 
be considered static there).

I forget the reason that we required staticness, but I think it had 
something to do with when the default expression is evaluated. It seemed 
confusing to do it just once at the point of declaration (most Ada defaults 
are re-evaluated), but we didn't want to incur the expense of having to 
evaluate an expression for every initialization. (Plus, there are some 
points where that wouldn't be sensible.) So I think we just gave up and 
required staticness. (But I might be totally mis-remembering this.)

> The drawback of the current restrictions (when T is private) is that the 
> responsibility for the assignment of a default value for the components of 
> the Vector type is placed on the /client/ of the generic package, who must 
> set the default value for the actual type T. Moreover, it is now 
> impossible to have different default component values for different arrays 
> declared in the generic, because type T can have only one default value.

Defaults always belong to a type, so by definition, they are always set at 
the point of the type declaration. Subtype-specific defaults caused a 
nightmare of problems since not every object has a well-defined nominal 
subtype. Thus, if the client is defining the type, they have to define the 
defaults. QED. :-)

As for the private type case, Ada is very strict about its contract model of 
generics, and we don't allow things that don't make sense. And defining a 
default component value of a non-scalar type doesn't make sense, because the 
component value can't be static. Thus it is never legal in a generic.

We adopted the restrictions on these aspects (Default_Value and 
Default_Component_Value) in order to make them tractable. Had someone 
insisted on allowing subtypes and non-static values, they become too complex 
to describe and implement. (They have effects on parameter passing and in 
aggregates as well as the "obvious" effects). I most likely would have voted 
to kill them in that case, and I think others were leaning the same way.

> One can imagine, for example, that T represents a value in some algebra 
> that has both a "zero" value (neutral element for addition) and a "one" 
> value (neutral element for multiplication), and that the generic package 
> would like to use "zero" as the default component value for one array type 
> ("array of sums") but use "one" as the default component value for another 
> array type ("array of products").

That problem is best solved by a reduction expression in Ada 2020, so no one 
will end up writing this generic anyway (they'll want to potentially 
parallel execution of a reduction expression). :-)

In any case, a default value is a convinience feature; no one ought to be 
writing uninitialized object declarations in the first place. And the 
semantics of this is *very* complex in the general case (you want to remove 
both the staticness requirement and the scalar requirement). I don't think 
it is possibly worth the headaches.

                                           Randy.