Re: null exclusion and generics

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

"Georg Bauhaus" <bauhaus@futureapps.de> wrote in message
news:1161262319.24061.19.camel@localhost.localdomain...
...
> Can I excpect, then, that Ada.Containers.* will typically
> not be usable with null excluding subtypes? (Because an
> implementation will likely declare local variables without
> knowing how to initialize them.)

Yes, that's probably true. And it will be true for pretty much any use you
might put a null-excluding subtype to.

Null-excluding subtypes were defined for object cases, like components or
parameters. They're not very useful as named subtypes, because they're
unlikely to work in many contexts (as you've noted here); they especially
won't match many generics (and if they do, the generic probably won't work).
A null-excluding *type* is even worse: it is virtually useless. Perhaps we
got a bit too orthogonal with them.

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

>Is it really so? I would expect them to require:
>
>   generic
>      type T (<>) is private;
>   procedure Nop(source: in T);
>
>for "not null" is a constraint.

No, a null-excluding type is definite, so (<>) isn't required. We didn't
want to add indefinite elementary types (just as we are unwilling to add
limited elementary types), because it would be a significant new concept - a
large burden on compilers without much benefit.

So all access types are initialized with null, and if the subtype is
null-excluding, that will automatically raise Constraint_Error. A null
exclusion is essentially a kind of constraint (it is not technically a
constraint, but that has to do with independence from other forms of
constraint). Think of  it being like:

    subtype A is Integer range 1 .. 10;

    Obj : A := Integer'First;

which also will raise C_E. (If we had allowed a way to declare automatic
initializations for scalar types -- something I wish we had done -- it would
have had a similar effect as the explicit initialization here).

                               Randy.