null exclusion and generics

null exclusion and generics

[Georg Bauhaus]

If a generic formal type is private, I can supply a
null excluding subtype for the type parameter.
A generic formal private type means assignment is possible.
Declarations of objects of the null excluding
actual inside the generic need explicit initialization,
though.

generic
   type T is private;
procedure Nop(source: in T);

procedure Nop(source: in T) is
   tmp: T;  -- no known way to initialize
begin
   tmp := source;
end Nop;

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.)

Is it a possible enhancement to add something like

generic
   type T is private;
   Default_Value: ...;  -- or a subprogram, or ...
...



-- Georg 

Re: null exclusion and generics

[Dmitry A. Kazakov]

On Thu, 19 Oct 2006 14:51:59 +0200, Georg Bauhaus wrote:

> If a generic formal type is private, I can supply a
> null excluding subtype for the type parameter.
> A generic formal private type means assignment is possible.
> Declarations of objects of the null excluding
> actual inside the generic need explicit initialization,
> though.
> 
> generic
>    type T is private;
> procedure Nop(source: in T);

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.

What would a language layer say?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: null exclusion and generics

[Randy Brukardt]

"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.

Re: null exclusion and generics

[Dmitry A. Kazakov]

On Thu, 19 Oct 2006 15:08:17 -0500, Randy Brukardt wrote:

> 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).

This is one more reason to finally introduce a sane
construction/destruction model in Ada. Compromises never buy off.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de