Version 1.3 of ais/ai-00447.txt

Unformatted version of ais/ai-00447.txt version 1.3
Other versions for file ais/ai-00447.txt

!standard 3.10 (06)          06-06-16 AI95-00447/02
!class binding interpretation 06-02-20
!status ARG Approved 12-0-1 06-06-09
!status work item 06-02-20
!status received 06-02-20
!priority High
!difficulty Easy
!subject Null_exclusions allowed in Ada 95
!summary
Ada 95 allows "not null" in anonymous access types, so that programs can be written that have the same semantics in both Ada 95 and Ada 2005.
!question
Ada 2005 introduces the null exclusion ("not null"), and correspondingly changes anonymous access types so that they don't automatically exclude null. That means that:
procedure P (A : access T);
has subtly different semantics in Ada 95 and Ada 2005. In mixed environments (which are likely to be common during the transition to Ada 2005), this poses a problem, as there is no way to write a program so as to get the same semantics in each language. This magnifies the effect of an otherwise minor incompatibility.
If "not null" was allowed in Ada 95 anonymous access types (optionally, of course), this problem would be substantially reduced. Should this be allowed? (YES! YES! YES!)
!recommendation
(See Summary.)
!wording
Replace 3.10(6) by:
access_definition ::= [not null] access subtype_mark
!discussion
The use of "not null" has no semantic effect in Ada 95. However, if the code using "not null" is compiled on an Ada 2005 implementation, the semantics will be unchanged, while the semantics will change if it is omitted.
The main objection to this change is that not all Ada 95 compilers will implement this change, and thus the portability of Ada 95 code will be reduced. In order to mitigate this issue, we encourage the ACAA to issue an Ada 95 ACATS test checking for this capability. This should have the effect of increasing awareness of the change amongst Ada vendors, and should encourage them to implement this easy change as soon as possible.
!ACATS test
Create/modify an ACATS test to check that "not null" is allowed, and properly raises Constraint_Error if passed null. (Note that there isn't a test for 4.6(49), so it is unclear whether this property is tested properly at all in the ACATS.)
!appendix

From: Randy Brukardt
Sent: Thursday, February  2, 2006  9:26 PM

Here's another comment from Canada for which the resolution
requires additional input to resolve.

The comment from Canada:

  Problem:

  There is an imbalance in the proposed new syntax for Ada 2005 with
  regard to null exclusion. Specifically, the new syntax allows the
  programmer to explicitly specify whether an access type excludes
  the null value, but there currently are no means for a programmer
  to explicitly specify whether an access type includes null.

  To exclude null, the programmer can add the clause "not null" to an
  access type definition in Ada 2005. In order to allow the
  programmer to specify that an access type can be assigned null
  values, the clause "accept null" seems like it would fit naturally
  into the syntax to convey that meaning.

  Conceptually, an accept statement in Ada defines which operations
  can be performed on a particular task. Here we are defining an
  operation that can be performed on a particular access type.

  Therefore, the following could all be valid;

     type my_access_type is access foo;
       --- Defaults to either not null or accept null depending on context as per Ada 2005
     type my_access_type is not null  access foo;
       -- Cannot be assigned null values
     type my_access_type is accept null access foo;
       -- Can be assigned null values

  The first form would be considered a short hand for either the
  second or the third form depending on whether the usage was for a
  controlling access type or not.

  Having a means to explicitly specify whether or not a type can accept
  null values helps to reduce the inconsistency in the treatment of
  the  first form for controlling vs non-controlling access
  types. There is no inconsistency when the second or third form is
  used. Having the third form means that there would always be a way
  to eliminate this inconsistency.

  This new proposed syntax means that the programmer will have a way
  to express exactly how the access type can be used with respect to
  null values. If the programmer specifies either "not null" or
  "accept null" then it is clear that the programmer has considered
  null usage, and further it allows the compiler to flag errors when
  the programmer is intending to use an access type in a manner that
  is not permitted.

  For example, if a programmer specifies "accept null" for a
  controlling access type, the compiler would generate an error at
  compile time.

  This also improves software maintainability and improves
  safety. For example if code is written where an access type can
  accept null, and later that code is modified so that the access
  type is made to be a controlling access type, the compiler can flag
  the need for changing the null exclusion whereever it is needed. If
  the first form is used, then there is an implicit change in how
  null values can be assigned which might introduce run time failures
  into the code.

  Note also that this feature can be added to the language without
  adding any new reserved words. The overriding and not overriding
  clause was added to Ada 2005 for very similar reasons, and
  apparently the reasons were considered strong enough to warrant
  adding a new reserved word to the language.

  Finally, note that it seems likely this feature would be relatively
  easy to implement for compiler vendors.

  Proposed revisions to AMENDMENT 1 (Draft 15) to support null_inclusion specification

  -------------------------------------------------------------------------
  Section 3.10
  Replace paragraph 2: [AI95-00231-01]
     access_type_definition ::=
     access_to_object_definition
     | access_to_subprogram_definition
  by:
     access_type_definition ::=
     [null_exclusion_indicator] access_to_object_definition
     | [null_exclusion_indicator] access_to_subprogram_definition

  Replace paragraph 6: [AI95-00231-01; AI95-00254-01; AI95-00404-01]
     access_definition ::= access subtype_mark
  by:
     null_exclusion_indicator ::=
        [null_inclusion | null_exclusion]

     null_inclusion ::= accept null
     null_exclusion ::= not null

     access_definition ::=
     [null_exclusion_indicator] access [constant] subtype_mark
     | [null_exclusion_indicator] access [protected] procedure parameter_profile
     | [null_exclusion_indicator] access [protected] function parameter_and_result_profile

  Replace paragraph 13: [AI95-00230-01; AI95-00231-01]
  For each (named) access type, there is a literal null which has a
  null access value designating no entity at all. The null value of a
  named access type is the default initial value of the type. Other
  values of an access type are obtained by evaluating an
  attribute_reference for the Access or Unchecked_Access attribute of
  an aliased view of an object or non-intrinsic subprogram, or, in
  the case of a named access-to-object type, an allocator, which
  returns an access value designating a newly created object (see
  3.10.2).
  by:
  For each access type, there is a null access value designating no
  entity at all, which can be obtained by (implicitly) converting the
  literal null to the access type. The null value of an access type
  is the default initial value of the type. Non-null values of an
  access-to-object type are obtained by evaluating an allocator,
  which returns an access value designating a newly created object
  (see 3.10.2), or in the case of a general access-to-object type,
  evaluating an attribute_reference for the Access or
  Unchecked_Access attribute of an aliased view of an
  object. Non-null values of an access-to-subprogram type are
  obtained by evaluating an attribute_reference for the Access
  attribute of a non-intrinsic subprogram.

  A null_inclusion in a construct specifies that the null value does
  belong to the access subtype defined by the construct, that is, the
  access subtype includes null.

  A null_exclusion in a construct specifies that the null value does
  not belong to the access subtype defined by  the construct, that
  is, the access subtype excludes null. In addition, the anonymous
  access subtype defined by the access_definition for a controlling
  access parameter (see 3.9.2) excludes null.

  Finally, for a subtype_indication without a
  null_exclusion_indicator, the subtype denoted by the
  subtype_indication excludes null if and only if the subtype denoted
  by the subtype_mark in the subtype_indication excludes null,
  otherwise the subtype denoted by the subtype_mark in the
  subtype_indication includes null.

  Replace paragraph 22: [AI95-00433-01]
     type Peripheral_Ref is access Peripheral; -- see 3.8.1
     type Binop_Ptr is access all Binary_Operation'Class;
     -- general access-to-class-wide, see 3.9.1
  by:
     type Peripheral_Ref is not null access Peripheral; -- see 3.8.1
     type Binop_Ptr is accept null access all Binary_Operation'Class;
     -- general access-to-class-wide, see 3.9.1

  Section 3.10.1
  Replace paragraph 7: [AI95-00326-01; AI95-00412-01]
      as the subtype_mark defining the subtype of a parameter or result of an
       access_to_subprogram_definition;
  by:
      as the subtype_mark in the subtype_indication of a subtype_declaration; the
       subtype_indication shall not have a null_exclusion_indicator or a constraint;

[End of comment from Canada]

---

This comment seems to come out of left field: the syntax for null exclusions
hasn't significantly changed since the concept was defined more than five
years ago. Moreover, WG 9 approved this syntax and semantics over 18 months
ago. Where was this comment when it would have been practical to change the
language?

The proposal *seems* simple enough, but it would be a very large change at
this point. It would be necessary to check all of the wording in the
standard for possible rewording. I'm dubious that the above are the only
changes needed. For instance, 6.1(13/2) and 6.1(15/2) use "null_exclusion";
it would seem necessary to change them and the associated wording as above.
That's true in other parts of the standard, as well.

Moreover, this would be "optional" syntax. That is, syntax which is not
required and duplicates the semantics of some other syntax (in this case,
the absence of syntax). We've had a very strong desire to avoid adding such
syntax in Ada 2005. Indeed, we removed the consistent "access all T" from
anonymous access types (over my object, BTW) to avoid this sort of syntax.

The intent of the current standard is that the *lack* of a null exclusion
indicates the ability to use null. That's true everywhere except for
controlling access parameters - for which using null is *never* allowed.
Since there are only two states, that certainly is sufficient to describe
them appropriately.

The concern about maintenance is certainly a real one. However, *adding* a
null exclusion to an existing subtype is almost never going to work; it is
very likely that many runtime failures will be triggered. OTOH, removing a
null exclusion or adding a null exclusion to an anonymous access type will
happen frequently. In all of these cases, the checks that change are runtime
checks. The additional of "accept null" would have no impact on these
runtime checks; the only cases were additional compile-time safety would
occur is on subtypes of access types. These are very rare, and it seems that
coding standards and/or restrictions identifier(s) could be used to avoid
problems with implicit inheritance of null exclusions. (That is, require
that null exclusions be repeated on subtypes for null excluding types; style
checkers and/or a restriction could enforce that).

Similarly, it would be useful if the confusing (but required for
compatibility) controlling access parameter could be detected and banned in
new code. Again, the best way to do that would be to have a restriction
identifier that banned "implicit" null exclusions. Something like
     No_Implicit_Null_Exclusions
         If the subtype_mark of a subtype_indication excludes null, a null_exclusion
         shall be included in the subtype_indication. All controlling access parameters
         shall include an explicit null_exclusion. This restriction applies only to the
         current compilation or environment, not the entire partition.

Conclusion: This proposal requires major rewording of the standard, provides
no significant additional capabilities (and the suggested Restriction would
provide the missing capability), and comes way too late in the process for
such a significant change.

---

ARG: Is additional compile-time checking worthwhile for null excluding
subtypes? Should we add a restriction similar to the one proposed above? Or
should we leave the best way to use this feature to the community to decide
(via style guides, style tools, and the like)?

*************************************************************

From: Jean-Pierre Rosen
Sent: Friday, February  3, 2006  1:38 AM

> ARG: Is additional compile-time checking worthwhile for null excluding
> subtypes? Should we add a restriction similar to the one proposed above? Or
> should we leave the best way to use this feature to the community to decide
> (via style guides, style tools, and the like)?
>

It could be done, but that does not mean it should be done.
Too much overkill for too little benefit for my taste.

*************************************************************

From: Pascal Leroy
Sent: Friday, February  3, 2006  3:46 AM

I am generally not too excited about restrictions that are purely
stylistic: clearly No_Implicit_Null_Exclusions would be one of those.  It
would not add any safety and it would not improve the generated code.  Its
only effect would be on legibility.  And even so I am unconvinced by the
definition you give: I can see the benefits for controlling parameters,
but the notion of repeating "not null" on every subtype sounds bogus to
me: we don't require that you repeat constraints on every subtype, for
instance.

I'd rather leave it to code rule checkers to enforce this kind of rules.
And we can always add the restriction later if we discover that there is a
strong demand from the community.

*************************************************************

From: Tucker Taft
Sent: Friday, February  3, 2006  7:09 AM

About the only change I might consider in this
area is to allow "'Base" to apply to access subtypes,
as a way to recover the null including, unconstrained
subtype, if the first subtype is null excluding.

Other than 'Base, we don't have a way of de-constraining
subtypes, and "accept null" would essentially be a way
of de-constraining something.  As far as the
"No_Implicit_Null_Exclusions" that is a restriction
that an implementor could add if there is demand
for it.  No need to pre-standardize that one at this
point.

*************************************************************

From: Pascal Leroy
Sent: Friday, February  3, 2006  7:38 AM

That crossed my mind, but remember that an access subtype can have both a
constraint and a null exclusion.  But then there is the question of
whether the 'Base attribute only drops the null exclusion, or both the
null exclusion and the constraint.  If the former, we are left with a base
subtype which is constrained, and that's strange.  If the latter, I fear
we go back to the Ada 83 mess with the Base attribute.

This might be worth considering in the future (after all we can add this
attribute compatibly at any time) but it seems too late for such a change.

*************************************************************

From: Tucker Taft
Sent: Friday, February  3, 2006  8:09 AM

To me there is only one "base subtype" and it would
include nulls and be unconstrained.

Can you remind me what was the Ada 83 mess with the
Base attribute?  I remember problems relating to
composite types, but none relating to access types.

*************************************************************

From: Pascal Leroy
Sent: Friday, February  3, 2006  8:22 AM

I would have to do some archeology, but I was under the impression that
access-to-composites had problems similar to composites.  Maybe just
FUD...

*************************************************************

From: Tucker Taft
Sent: Friday, February  3, 2006 11:27 AM

My memory of the problem of 'Base on composites is that
if the first subtype of a derived composite type is
constrained, then it is possible to create a record
rep clause that works for the first subtype, but requires
a bizarre and unsupported representation for an
unconstrained subtype.  I don't see that this would
apply to an access-to-composite subtype, since the designated
subtype must be unconstrained in the first place
if you can apply a constraint to an access type.

So I *think* 'Base on an access subtype would be well defined,
and could be useful, especially in a generic, to be able
to declare null-including temporaries of a generic formal
null-excluding access type.

But hardly anything earth-shattering, and probably not
compelling enough for a change at this point.

*************************************************************

From: Robert A. Duff
Sent: Friday, February  3, 2006  2:06 PM

> ARG: Is additional compile-time checking worthwhile for null excluding
> subtypes? Should we add a restriction similar to the one proposed above? Or
> should we leave the best way to use this feature to the community to decide
> (via style guides, style tools, and the like)?

I'll say the same thing I said about "Case sensitivity in Directories,
Environment_Variables": This proposal has technical merit but, I think it's
way too late for this sort of thing.

Note that we would have to argue about "accept null" vs. "with null".

ARG can always address these kinds of issues after the standard is
standardized.

*************************************************************

From: Pascal Leroy
Sent: Saturday, February  4, 2006  4:11 AM

> Note that we would have to argue about "accept null" vs. "with null".

Just for the record, I would much prefer Tuck's idea of extending the Base
attribute, than inventing special syntax.  The Base attribute seems more
consistent with the existing language, and it can be added later with much
less disruption.

*************************************************************

From: Robert Dewar
Sent: Monday, February  6, 2006  2:00 PM

>> ARG: Is additional compile-time checking worthwhile for null excluding
>> subtypes? Should we add a restriction similar to the one proposed
>> above? Or
>> should we leave the best way to use this feature to the community to
>> decide
>> (via style guides, style tools, and the like)?
>>
>
> It could be done, but that does not mean it should be done.
> Too much overkill for too little benefit for my taste.

I agree, this is unnecessary (of course if Canada wants to
spend a silver bullet on this, we can reconsider :-)

*************************************************************

From: Robert Dewar
Sent: Monday, February  6, 2006  2:01 PM

> Note that we would have to argue about "accept null" vs. "with null".

I far prefer "with null" if we do add either.

*************************************************************

From: Robert Dewar
Sent: Monday, February  6, 2006  8:14 PM

>> It could be done, but that does not mean it should be done.
>> Too much overkill for too little benefit for my taste.
>
> I agree, this is unnecessary (of course if Canada wants to
> spend a silver bullet on this, we can reconsider :-)

See my future notes on this, where I changed my mind on
this issue. I am now in favor of changing the name.

*************************************************************

From: Randy Brukardt
Sent: Monday, February  6, 2006  8:33 PM

Careful: there are three unrelated comments that I asked about. You
commented on a message about "null inclusion" (and it appeared that is what
you were talking about in this old mail). Your more recent notes are on
Ada.Directories.Rename - I don't think you changed your mind on "null
inclusion".

*************************************************************

From: Robert Dewar
Sent: Monday, February  6, 2006  8:33 PM

My mistake, got threads mixed up (and was indeed surprised when
I saw dewar-1 making an odd comment that dewar-2 disagreed with).

Summary: move issue, I think the name should be changed

Null inclusion: seems overkill, i agree no change here.

*************************************************************

From: Robert Dewar
Sent: Monday, February  6, 2006  11:26 PM

dewar-2 is also having second thoughts about this one.

It continues to bother me that we have introduced a
serious incompatibility in Ada 2005 in this area
(previously correct programs silently converted
to be erroneous in Ada 2005).

If we adopated the Canadian proposals it would provide
an effective method to guard against the consequences
of this incompatible change.

*************************************************************

From: Randy Brukardt
Sent: Monday, February  6, 2006  11:50 PM

Would you care to elaborate? I'm not sure I see what help the extra,
optional, keywords would be. You'd still have to put them in, and if you did
that, you wouldn't have a problem (because you would put "not null" into
existing code). The problem seems to mainly be one of backward
compatibility: if you want your code to be both Ada 95 and Ada 2005, you
have a problem because you can't get consistent behavior in both versions.
(Otherwise, converting permanently to Ada 2005 can be automated: simply add
"not null" to every access parameter. Probably an ASIS tool would have no
problem doing that.) Adding more keywords won't help that - if anything it
would make it worse. So what am I missing?

*************************************************************

From: Robert Dewar
Sent: Tuesday, February  7, 2006  12:11 AM

If you have a config pragma that requires the keywords, then you
can guarantee that no bad situations get carried forward on a port,
or get introduced after the port.

We have a serious case of incompatibility here, so it is useful to have
a compiler option that makes it *really* incompatible, forcing the
change. Your note above says that you can do the change manually.
Fine, but it is useful to be able to force it.

Without this feature there is no way to tell if

    (A : access Integer)

is a not null case that someone forgot to label on the port, or
accidentally introduced after the port, forgetting the incompatiblity.
with the pragma in place, this is illegal, and you are forced to
write either

   (A : not null access integer) or
   (A : with null acess integer)

or whatever the syntax is ...

and the potential mistakes that can come from the (really
horrible) incompatible change are mitigated.

*************************************************************

From: Robert Dewar
Sent: Tuesday, February  7, 2006  12:13 AM

> if you want your code to be both Ada 95 and Ada 2005, you
> have a problem because you can't get consistent behavior in both versions.

Due to this incompatible change, it is IMPOSSIBLE to have code
that is both Ada 95 and Ada 2005. This is horrible, but true
regardless of whether these new keywords are introduced.

What a nasty mess!

*************************************************************

From: Tucker Taft
Sent: Tuesday, February  7, 2006   1:16 AM

> Due to this incompatible change, it is IMPOSSIBLE to have code
> that is both Ada 95 and Ada 2005. This is horrible, but true
> regardless of whether these new keywords are introduced.

I feel like we plowed this ground pretty thoroughly before,
and I don't see the Canadian proposal helping significantly.

> What a nasty mess!

The incompatibility is that for non-controlling access
parameters, if you don't add a not-null (in other words,
retain the Ada 95 code as is), then you will now be
able to pass null.  But the existing code presumably doesn't
do that.  So the only "incompatibility" would be new code
that takes advantage (intentionally or not) of the new
permission.  But this new code is likely going to
be slipping into other Ada 2005'isms, so it probably won't
remain backward compatible anyway.

If you definitely want to be able to use both an
Ada 95 and an Ada 2005 compiler interchangeably, then clearly
you don't want to take advantage of passing null.
If want that to be checked, then a possible thing to do
during the transition period is to add in the subprogram's
declarative part, for every non-controlling access param of
the form "Param: access Desig" a rename at the beginning of the
subprogram:

     Deref : Desig renames Param.all;

This will fail with a Constraint_Error in Ada 2005 if the
caller passed in a null.  The same exception handler will
handle the error as in Ada 95, presuming these renames are
in the outermost declarative part of the subprogram.

*************************************************************

From: Robert Dewar
Sent: Tuesday, February  7, 2006  1:23 AM

> The incompatibility is that for non-controlling access
> parameters, if you don't add a not-null (in other words,
> retain the Ada 95 code as is), then you will now be
> able to pass null.  But the existing code presumably doesn't
> do that.

Existing code may rely on an exception from trying
to pass null.

>
>     Deref : Desig renames Param.all;
>
> This will fail with a Constraint_Error in Ada 2005 if the
> caller passed in a null.  The same exception handler will
> handle the error as in Ada 95, presuming these renames are
> in the outermost declarative part of the subprogram.
>

interesting kludge. Worth a note at least in the AARM.

But I see the Canadian proposal as valuable for making
the code transition to Ada 2005, not trying to maintain
compatibility with Ada 95.

*************************************************************

From: Stephen Michell
Sent: Tuesday, February  7, 2006  8:09 AM

There has been a lot of discussion about this comment, but the basic fact is
that there is an incompatibility which needs improvement. Our proposal (accept
null) is along the lines of the "overriding/not overriding" discussion that led
to the addition of a keyword. We think that the issue is important from the
incompatibility and the documentation perspective.

In our discussions that led to this comment, we were not married to "accept
null", we were simply searching for a compound keyword that would match the
intent. "with null" would probably be acceptable also.

*************************************************************

From: Robert A. Duff
Sent: Tuesday, February  7, 2006  3:52 PM

How about "not not null".  ;-) ;-)

*************************************************************

From: Tucker Taft
Sent: Tuesday, February  7, 2006  4:06 PM

I think this is overkill for a minor incompatibility.
We have generally not worried about incompatibilities
that remove the raising of predefined exceptions,
as handling such exceptions and presuming they
are raised "precisely" is generally considered
"bad form."

I realize that *any* incompatibility can be cause for
concern, but we have to be very careful that the cure
is not worse than the disease.  In this case, I think
the cure will make the language more confusing and
more complex, with relatively small, transient benefit.

Providing 'Base on access subtypes would be a very minor
change and provide some additional degree of uniformity,
if it is felt to be essential to emphasize the lack of
a null exclusion.  Even that seems overkill in my view,
especially at this late date.  But it would be a more
consistent and appropriate "fix" if one is felt essential.

*************************************************************

From: Randy Brukardt
Sent: Tuesday, February  7, 2006  4:16 PM

> There has been a lot of discussion about this comment, but the basic fact is that
> there is an incompatibility which needs improvement. Our proposal (accept null)
> is along the lines of the "overriding/not overriding" discussion that led to
> the addition of a keyword. We think that the issue is important from the
> incompatibility and the documentation perspective.

Well, this proposal does nothing whatsoever for the incompatibility, because
"with null" and the current syntax of saying nothing would have the exact
same semantics. (I'm assuming that "widening" subtypes are banned with
appropriate legality rules.) There are only two states here! That's not true
with "overriding"/"not overriding"; there are *three* states: "O", "~O", and
"don't care". There's no "don't care" here, because "don't care" and "with
null" have identical semantics.

The only way to fix the incompatibility is to totally abandon the existing
"access T" syntax. Indeed, we originally did that:
    access all T
    access constant T
    not null access all T
    not null access constant T
where the original
    access T
is equivalent to "not null access all T" and it is moved to Annex J.

The reason we didn't do that was that users thought that the new syntax was
too wordy, and they (specifically AdaCore people) thought that everyone
would use the shortcut anyway, *and* it ould be confusing.

I would expect that same comment to apply to other unnecessarily wordy
syntax as well. That is, no one will use "with null access T" because it
takes up too much space. So why bother?

In any case, I would object to just trying to band-aid this. We need to go
back to first principles if the current solution is not considered
acceptable. Particularly if the band-aid doesn't fix the problem.

My big objection to the current rules is the *lack* of explicit "not null"
on controlling parameters. I'd prefer to allow "not null" in Ada 95
compilers (for backward compatibility) and then *require* it in controlling
parameters (thus getting errors if the parameters aren't changed. That's
quite incompatible (in the sense that correct Ada 95 code won't compile),
but this is a mechanical change.

*************************************************************

From: Stephen Michell
Sent: Thursday, February  9, 2006  10:28 AM

I am attaching additional info from Brad. He has been examining the connection
with Generics also, as you can see when you read his notes.

Randy's comments that this is 3-option as opposed to overriding's 2-option is
false. The third option in overriding is that you don't use either and get the
Ada95 behaviour.

Canada is not going to use a silver bullet (or even a wooden stake) on this. We
will live by the ARG's judgement (and of course I have to vote).

---

Note: This discussion is derived from the paper by John Barnes,
Rationale for Ada 2005, section 5 on Exceptions and Generics. Examples
and text were taken and either directly copied or modified from that
document.


There are further cases that can be made in support for adding explicit null
inclusion syntax to Ada.

First of all, consider the syntax;

   type Ref_ANT is access T;
   type Ref_NNT is not null access T;
   type Another_Ref_NNT is new access Ref_NNT ;        -- Excludes null

According to the current proposal for Ada 2005, there is a rule that
states that a type derived from a type that excludes null also
excludes null. There are two issues to look at here. First of all,
looking just at the declaration for the derived type which can be
physically located in a different package than the base type, one
cannot determine if the type includes null or excludes null. If
someone changes the null inclusion indicator of the base type it
affects the derived type and could lead to unexpected consequences for
the derived type. It could be a recommended practice to explicitly
state in the derived type whether or not the derived type excludes
null or not as in;

   type Another_Ref_NNT is new not null access Ref_NNT ;        -- Excludes null

That way, changes to the null exclusion indicator of the base type
would not affect the derived type.
For the same reason it would be useful to write;

   type Another_Ref_ANT is new accept null access Ref_ANT ;        -- Includes null

This would insulate the derived type from changes to the base
type. Also, if we maintain the current language syntax whereby we
cannot derive a type that includes null from a type that excludes
null, the compiler could flag this error at compile time. Without this
syntax, using an implicit null inclusion, any problems associated with
changing the base type on the derived type would likely not get caught
until run time.

Note that the language currently does not support deriving a new type
that includes null from a type that excludes null. This might be a
useful feature to add to the language, although it would be a bit of a
departure in some ways from the existing language syntax whereby new
types can be created that add constraints to existing types, but
cannot remove constraints. On the other hand, null exclusion is not
meant to be considered as a constraint according to the proposed
languages specification.

In other words, should it be possible to write a statement such as;

   type Ref_DANT is new accept null access Ref_NNT ;   -- Should this be legal?

For example, perhaps the rule should be changed to state that a type
derived from a type that excludes null does not excludes null unless
explicitly stated such as

   type Another_Ref_DANT is new access Ref_NNT;         -- Includes Null
   type Another_Ref_DNNT is new not null access Ref_NNT;   -- Excludes null

One advantage of this approach is that one can tell whether or not a
derived type includes or excludes null simply by looking at the
declaration for the derived type.

Coming up with an answer to these questions are likely to be a source
of debate. However, whether or not such the language allows deriving a
type that includes null from a type that excludes null does not impact
the usefulness of being able to explicitly declare whether a type can
include or exclude null. It probably makes the most sense to disallow
deriving a type that includes null from a type that excludes null from
the consistency standpoint and to minimize changes to the language,
especially considering the current timeline in the Ada 2005 standard
approval process.

Note however that;

   type New_Ref_ANT is accept null access T;                  -- Includes Null
   type New_Ref_NNT is new not null access Ref_NNT;   -- Excludes null

Should be allowed, since there is no reason for disallowing this, and
because the language currently supports deriving a type that excludes
null from a type that includes null.

Now consider generic units. There are inconsistencies in the language
that can be alleviated by adding explicit null inclusion.

In the current Ada 2005 syntax we allow formal access type parameters of the form;

   generic
      ...
      type A is not null access T;
      ...

Where the actual type corresponding to A must then itself be an access
type that excludes null. A similar rule currently applies in
reverse - if the formal parameter excludes null then the actual
parameter must also exclude null.

With the addition of null inclusion we would also then be able to write;

   generic
      ...
      type B is accept null access T;
      ...

From the rules mentioned above for the first form, it follows that the
actual type corresponding to B must then itself be an access type that
includes null. Furthermore, a similar rule would also apply in
reverse, that is, if the formal parameter includes null then the
actual parameter must also include null. This is a clean symmetrical
syntax, which is desirable.

In the case of the original Ada syntax;

   generic
      ...
      type B is access T;

The existing syntax remains backwards compatible with Ada 95, where
this form is generally considered a short form for the explicit accept
null syntax above.

An asymmetry in the syntax occurs when we consider when anonymous
access types are now used for generic formal parameters. This
asymmetry can be alleviated through the use of explicit null inclusion
For example, we could write;

   generic
      A: access T := null;
      AN: in out not null access T;
      AA: in out accept null access T;
      F: access function (X: Float) return Float;
      FN: not null access function (X: Float) return Float;
      FA: accept null access function (X: Float) return Float;

Currently, in the proposed Ada 2005 syntax, If the subtype of the
formal object excludes null (as in AN and FN) then the actual must
also exclude null but not vice versa. This contrasts with the rule for
formal access types discussed above in which case both the formal type
and actual type have to exclude null or not. According to the proposed
standard, A and F above might exclude null or might not.

With explicit null inclusion, this could be interpreted as an
indication that stronger type checking is desired and that the actual
generic parameters cannot exclude null. This provides a more
symmetrical view to match the case for null exclusion so that we now
can state;

   1)If the subtype of the formal object excludes null (as in AN and
   FN) then the actual must also exclude null

   2)If the subtype of the formal object explicitly includes null (as
   in AA and FA) then the actual must also include null either
   explicitly or implicitly.

   3)If the subtype of the formal object implicitly includes null (as
     in A and F), then the actual can either exclude null or include
     null.

The ability to explicitly specify null inclusion leads to improved
efficiency in the generic code and improved safety and security.

If we explicitly specify accept null for a generic formal object, then
the generic code would not need to check for null internally. Without
accept null, the code needs to check for null since a type that
excludes null can be passed into the generic into a parameter that
includes null.

Also, the generic could conceivably pass a reference to a generic
parameter to a library function that sets the access type variable to
a null value. This could lead to run time errors that could have been
caught at compile time. If the writer of the generic knows that null
values could get assigned to access variables, the writer of that
generic could specify accept null on that generic parameter which
would force the user of the generic to pass in a type that does not
exclude null.

Similarly, if the subprogram profile itself has access parameters that
exclude null as in;

   generic
      PN: access procedure (AN: not null access T);

then the actual subprogram must also have access parameters that exclude null.
The same rule applies to named formal subprogram parameters. If we have;

   generic
      with procedure P(AN: not null access T);
      with procedure Q(AN: access T);

then the actual corresponding to P must have a parameter that excludes
null but the actual corresponding to Q might or might not.

If we could write

   generic
      PAN: access procedure (AN: accept null access T);

Or;

generic
with procedure R(AN: accept null access T);

We would have a way to specify that the actual subprograms have access
parameters that must include null. The implicit declaration would
remain as before where the actual parameter may or may not exclude
null. This provides similar improvements for efficiency, safety and
security as mentioned above, yet provides the flexibility to accept
parameters that can either include or exclude null.

As a final note, consider that there are cases where it is not
possible to explicitly indicate null inclusion or exclusion.

Suppose we have;

   generic
      type T is private;
      with procedure P(Z: in T);
    package G is

This can be matched by

   type A is access ...;
   procedure Q(Y: in not null A);
   ...
   package NG is new G(T => A; P => Q);

Note that since the formal type T is not known to be an access type in
the generic declaration, there is no mechanism for applying a null
exclusion to it. Nevertheless there is no reason why the
instantiation should not be permitted. This means that we still need
to be able to rely on implicit null inclusion. In other words we could
not have the compiler force the programmer to always explicitly
specify whether the parameter excludes null or not. There are times
when the programmer might want a type derived from a base type to have
the same null inclusion/exclusion specification. The implicit
declaration remains a way to do this.

In summary, this proposal for explicit null inclusion provides more
flexibility for the programmer, improved efficiency, and improved
safety and security. All are important considerations for the overall
design goals of Ada.

*************************************************************

From: Randy Brukardt
Sent: Thursday, February  9, 2006  3:27 PM

> Randy's comments that this is 3-option as opposed to overriding's 2-option
> is false. The third option in overriding is that you don't use either
> and get the Ada95 behaviour.

You have my statement backwards. I said that overriding is the 3-option case:
overriding, not overriding, "don't care" - the Ada 95 option.

The original proposal you sent only has two states: "not null" and "accept
null"/nothing, because there was no special semantics associated with
"accept null". There isn't much point in having two syntaxes for one state;
that's something we've tried to avoid.

*************************************************************

From: Randy Brukardt
Sent: Thursday, February  9, 2006  4:22 PM

> I am attaching additional info from Brad. He has been examining
> the connection with Generics also, as you can see when you read his notes.

I suspect that this issue comes down to how you expect null exclusions to be
used. I think that they will be primarily useful in parameters and
discriminants (both for anonymous and named subtypes). And occasionally
useful for stand-alone objects.

As such, it will almost always be used directly in the parameter,
discriminant, or object declaration:
    Param : in not null My_Access;
    Other_P : access not null Typ;
    Obj : not null My_Access;

That has the best readability.

I think named subtypes will be rare, and types will be exceedingly rare.
(The latter because you can't use Unchecked_Deallocation with them.) Named
subtypes would have to include "not_null_" or some equivalent in the name in
order to keep the readability up, at which point there is no real benefit to
the named subtype.

Note that most of issues that Brad talks can't even exist without named
subtypes. For instance, he says:

> According to the current proposal for Ada 2005, there is a rule that
> states that a type derived from a type that excludes null also
> excludes null. There are two issues to look at here. First of all,
> looking just at the declaration for the derived type which can be
> physically located in a different package than the base type, one
> cannot determine if the type includes null or excludes null. If
> someone changes the null inclusion indicator of the base type it
> affects the derived type and could lead to unexpected consequences for
> the derived type.

Since it will be very rare to even have a named subtype with a null
exclusion, it seems even more unlikely to be deriving a type from such a
thing. (And, as previously mentioned, such a type would be nearly useless,
as it couldn't use Unchecked_Deallocation. Even if it existed, it probably
wouldn't survive long.)

It's also the case, of course, that Ada derived types work this way for
everything else:

   type AINT is range 0 .. 100;
   type Another_AINT is new AINT;        -- Has range 0 .. 100

And certainly a AINT could be far away, a change could have unexpected
consequences, etc. Moreover, this is often what you want: derived types are
often used as a poor-man's rename, and you *want* to inherit all of the
characteristics.

The same goes for generic formal objects (the constraint comes from the
actual object, not the subtype given in the generic -- the generic body
shouldn't depend on any particular constraint), and parameters of generic
formal subprograms (the constraints come from the actual, not the formal
subtypes).

Ada 2005 actually goes beyond the Ada norm and tries to provide some
checking in these cases. But it should be clear that it is the checking that
is anomalous, not the notion that it doesn't go far enough. The obvious
solution to these complaints is to revert to the Ada 95 rules (no checking
at all), which would be more consistent with the rest of the language.

Anyway, if you think that there will be a lot of use of null exclusions
outside of parameters, you might be concerned about the Ada 2005 rules. But
I think that few users will ever run into these cases, and fewer in ways
that would matter.

Note that Brad's note seems to imply a number of changes to legality rules:
for renames, for generic matching, for static matching, for derivation, for
parameters, etc. The proposal that was submitted did not include any of
these rule changes, and thus there was no additional checking in the
proposal. That may have contributed to the reaction to it.

The good thing about this proposal is that it appears fully compatible (in
that no changes in the behavior of access types with no exclusion or
inclusion are made), so that it could be added in the future without a
problem. That means that if we decide not to add it now, it still could be
added in the future.

*************************************************************

From: Stephen Michell
Sent: Friday, February 10, 2006  8:26 AM

My understanding of the current situation is that if you derive from a "not
null" construct, you do not need to say "not null" again, so you get what the
original one was, but you don't know it unless you go to the root and check, so
it is also ambiguous.

*************************************************************

From: Robert Dewar
Sent: Friday, February 10, 2006  8:36 AM

> The phrasing of the question made it impossible to answer. The issue is not what most
> programmers would use it for, but what serious projects would demand. My position is that,
> just like "overriding" and "not overriding", serious projects would put in place a coding
> rule that you must use "not null" or "accept/with null" for all access types that you
> declare to prevent unforseen clashes and use the compile time checking to improve the code.

By the way, it is this important usage (a coding restriction of the
kind mentioned above) that makes the proposal useful, and thus
Tucker's proposal is completely irrelevant as a "solution" to the
problem that I see as needing to be solved, which is to avoid
problems caused by this nasty incompatibility.

Why is this incompatibiliy nasty?

Because in moving to Ada 2005, everyone will ask: "is Ada 2005 upwards
compatible with Ada 95". It would be nice to answer yes! Well we can't
quite do that anyway because of new keywords, so the answer we would
like is

"almost completely, and those few cases of incompatibility that exist,
the compiler will always diagnose the problem."

well we can't even do that, because of the wide character changes, so
perhaps

"almost completely, with two exceptions. There are some new keywords
so the compiler will diagnose any misuse of these and the problem
is easily fixed. Also there are some changes in the handling of
wide characters, which won't affect anyone not using this feature,
and which furthermore almost certainly fix previous problems rather
than create new problems."

But the null access point is something that is much more delicate,
we have to add

Finally, the meaning of access parameters has been changed. This
can silently affect the behavior of existing programs, even
resulting in the appearence of erroneous execution.

You will have to carefully check every use of access parameters
and add NOT NULL wherever the program is counting on this. You
can just add these keywords unconditionally to all current Ada 95
usage, and then you are guaranteed unchanged behavior in Ada 2005."

This last advice would be more convincing if

a) we allowed the keywords to be added in Ada 95 mode

that's an absolute minimum in my view

b) we allow the WITH NULL (or whatever) alternative, so that we
can avoid mistakes being introduced by Ada programmers who are
not sufficiently aware of this significant change in the
language.

As Steve said, the idea would be to have a coding requirement
(possibly enforced by a standard pragma) that would force you
to write NOT NULL or WITH NULL. Then any programmer not knowing
about this issue would leave out the keywords, get a rejection
and be forced to find out about the issue and make the proper
choice.

For consistency, one might consider allowing WITH NULL on
any access type (after all it was worrying about consistency
that lead to the decision to tolerate a worst-case non
upwards compatibility) [worst case here does not refer to
the likelyhood of this causing trouble, but rather the
fact that it is the kind of incompatibility that silently
causes a difference in behavior).

One aspect that I think sometimes the ARG does not sufficiently
well understand is that many Ada users are dealing with huge
programs that they do not know well. They are interested in
the possibility of using some Ada 2005 features in a
conservative manner, but an incompatibility of this
nature is going to really worry some users.

We see the same phenomenon when we notify people of a highly
obscure bug in the compiler. We know that in practice it is
not going to occur in existing programs, but people worry
about how they can make sure of this.

I also don't think people want a precipice effect, that the
transition to Ada 2005 means making source modifications
that make it impossible to return to Ada 95. That's why
officially allowing NOT NULL in Ada 95 programs is
important.

Yes, of course compiler writers can allow this under some
switch, but many of the same users are also nervous about
using special switches that corresond to non-standard
behavior.

So blessing the possibility of putting NOT NULL in Ada 95
programs will in practice be a big help in dealing with
this problem.

After all, if we go just this far, people could have a
coding standard that required the use of NOT NULL in
*all* access parameters all the time.

They would not be able to take advantage of the marginal
value of the new feature in Ada 2005, but that's not so
terrible, and may seem a lot better than risking wandering
into incompatibility territory.

*************************************************************

From: Robert A. Duff
Sent: Friday, February 10, 2006  9:01 AM

> a) we allowed the keywords to be added in Ada 95 mode
>
> that's an absolute minimum in my view

I agree.  Especially if the compiler writers around here commit to doing so.

*************************************************************

From: Randy Brukardt
Sent: Friday, February 10, 2006  1:38 PM

I third this notion. In fact, I would suggest that we pass a resolution
suggesting that the ACAA issue an ACATS test for this (that needs a
resolution because WG 9 has suggested that the ACAA not issue new Ada 95
tests; additionally, a resolution would allow adding the test immediately,
without the normal waiting period), and thus we would encourage *all*
compilers to support this ASAP.

That, plus agreement from the vendors here, would get this done at "the
speed of light"; most users would have the capability in their hands by the
end of the year. (Users that don't update compilers aren't going to be
transitioning to Ada 2005 anyway.)

To this point, the vote on the letter ballot on this question was 5-2-4;
that's not a clear consensus, but it seems that we lean toward allowing the
keywords in Ada 95. Perhaps we can figure out a way to build consensus on
this issue. Those of you that are against this or abstained: what's the
concern? Can it be addressed? This is a semantic-free proposal, after all.

*************************************************************

From: Tucker Taft
Sent: Friday, February 10, 2006  2:32 PM

I believe I explained my abstention -- I didn't
think it mattered, since vendors can do this if
they want today.  I am quite happy to go along
if others feel strongly, since I see absolutely
no harm in doing this, except perhaps expecting
too much from it.

*************************************************************

From: Gary Dismukes
Sent: Friday, February 10, 2006  3:19 PM

But they can't necessarily do it with a clear conscience, which
is why it would be better to have an official blessing. :-)

Also, it would be nice if all vendors would agree to do this
to aid portability.

*************************************************************

From: Robert Dewar
Sent: Friday, February 10, 2006  4:35 PM

> But they can't necessarily do it with a clear conscience, which
> is why it would be better to have an official blessing. :-)

I think this misses the point. They can't do it except under
a non-standard switch, and many customers have a policy of
avoiding anything that is officially non-standard.
>
> Also, it would be nice if all vendors would agree to do this
> to aid portability.

Well I think whether vendors follow something like this is
up to them and their judgment of what the market requires.
You could also say it would be nice if all vendors would
agree to get their compilers validated to aid portability,
but in fact no vendor is bothering with validation at the
moment, since there simply is not a market demand for
formal validation (at least we don't see any!)

*************************************************************

From: Robert Dewar
Sent: Friday, February 10, 2006  4:54 PM

> That, plus agreement from the vendors here, would get this done at "the
> speed of light"; most users would have the capability in their hands by the
> end of the year. (Users that don't update compilers aren't going to be
> transitioning to Ada 2005 anyway.)

You certainly have the agreement of AdaCore. We actually implemented
this based on the earlier AI, and then removed the implementation
when the ARG changed its mind.

*************************************************************

From: Robert Dewar
Sent: Friday, February 10, 2006  4:58 PM

> I believe I explained my abstention -- I didn't
> think it mattered, since vendors can do this if
> they want today.  I am quite happy to go along
> if others feel strongly, since I see absolutely
> no harm in doing this, except perhaps expecting
> too much from it.

All I expect is that I will be able to tell my users the
following:

One incompatibility that has to be checked is the change
in the meaning of access parameters. In Ada 95, you could
count on them being non-null (and CE being raised on an
attempt to pass null). In Ada 2005, by default access
parameters do permit null. This is generally much more
convenient, but does result in possible incompatible
behavior.

In Ada 2005, you can solve this problem by labeling
your access parameters as NOT NULL, resulting in
Ada 95 compatible behavior. As a preparation to
making a transition to Ada 2005, you can ensure that
this incompatibility by labeling all existing access
parameters NOT NULL and in fact we
provide a tool for making these changes to your
sources automatically.

To aid this transition, the NOT NULL keywords are now
allowed in Ada 95 mode now (this is an official change
to the Ada 95 language), so if you do this, you will
still be able to compile in Ada 95 mode (assuming that
the Ada 95 compiler you use respects this latest
change, which GNAT Pro most certainly does).

*************************************************************

From: Pascal Leroy
Sent: Monday, February 13, 2006 11:08 AM

You'll find below the results of the letter ballot on the Canadian
proposal.  I am only including the numerical results, not the comments
that came with the votes, as you have seen them already.

The results of multiway, non-independent votes are always hard to
interpret, but someone has to do it, so here are my conclusions:

1 - There is a clear consensus against changing the syntax/semantics of
anonymous access types as proposed by the Canadian delegation.
2 - There is a majority in favor of allowing "not null" in Ada 95.
3 - The documentation benefits of "accept null" (or whatever the syntax)
are felt to be insufficient.
4 - The syntax "with null" is preferred over "accept null" (but this is
pretty irrelevant given the result for question 3).
5 - Widening of subtypes is considered unpleasant.
6 - The potential confusion regarding controlling parameter is not that
bad.
7 - We have no idea whether people would use optional syntax consistently
or not (bad experience with "in" parameters?).
8 - Tuck's 'Base idea has some appeal.
9 - It is very much unclear whether Tuck's 'Base idea would actually solve
the problems raised by the Canadian delegation.

These results lead to the following action items:

Randy: Proceed with the preparation of draft 16 of the Amendment *without*
including the Canadian proposal on null inclusion.
Randy: Prepare a BI for consideration at the Oporto meeting to allow "not
null" in Ada 95.  (Since this is a change to Ada 95, it doesn't impact the
Amendment, so it can wait until the next meeting.)
Tuck: Prepare an AI for consideration at the Oporto meeting to allow 'Base
for access types.

Pascal

--
Voting: Baird, Barnes, Brukardt, Burns, Dewar, Dismukes, Duff, Eachus,
Leroy, Michell, Ploedereder, Rosen, Taft, Tokar.

1) Should the syntax and semantics of anonymous access types be revisited
to reduce or eliminate the incompatibilities introduced for access
parameters?

         ___ Yes, the incompatibility is critical, it must be eliminated.
         _2_ Yes, the incompatibility is important, but other
             considerations also apply.
         _1_ No, the incompatibility is unlikely to matter in practice.
         11_ No, the incompatibility isn't that serious and the
             delay in the Amendment required to revisit (at least
             6 months) is unacceptable.

2) One proposed way to mitigate the compatibility problem is to allow "not
null" in access parameters and discriminants
(optionally) in Ada 95 programs. (The meaning would be the same whether or
not it is present.) That way, users could write code now that won't have
problems on porting.

         _8_ Yes, allow "not null" in Ada 95 programs.
         _2_ No, do not allow "not null" in Ada 95 programs.
         _4_ Abstain

3) Canada suggests adding "accept null" to explicitly specify the opposite
of null exclusion. Are the documentation benefits of this sufficient to
add it?

         _3_ Yes.
         11_ No.

4) If the Canadian proposal goes forward, which syntax would you prefer?

         _1_ "accept null"
         12_ "with null"
         _1_ Abstain

5) The Canadian proposal allows subtype "widening", that is, for a subtype
to be less constrained than its parent subtype. That's a new concept in
Ada. Specifically,
        subtype Foo is not null Acc;
        subtype Bar is accept null Acc;
Subtype Bar has more values than its parent, Foo. Should this be allowed?

        _1_ Yes, this is OK.
        _10_ No, Bar should be illegal.
        _3_ Abstain.

6) The intent of the Canadian proposal is to increase the possibility of
compile-time checking for controlling parameters and (possibly) subtypes.
Should the proposed Amendment be revisited to address this?

        _2_ Yes, controlling parameters are likely to be confusing.
        11_ No, this isn't important enough for the time it would take.
        _1_ Abstain

7) Wordiness was the original reason for introducing the incompatibility;
users felt that the old syntax "access T" was too convenient to abandon.
Similarly, the optional "all" was dropped because it was felt no one would
use it and it signified no semantics. The Canadian proposal would also
increase the wordiness of access parameters when it is used. In your
opinion, will users use the "accept null" syntax if it is added to the
language?

        _1_ Yes, the added documentation is compelling.
        _5_ Maybe, it would be used like "in" for parameters:
            inconsistently.
        _6_ No, most programmers will use the shortest correct form.
        _2_ Abstain.

8) Tucker has proposed allowing 'Base on access subtypes to allow getting
to an access subtype that is not encumbered with a null exclusion. This
would allow the "widening" of the Canadian proposal without adding any new
concepts. Is this worth doing?

        _2_ Yes, the ability to reach unconstrained access types would be
useful.
        _8_ Yes, (as above), but this isn't important enough to do now.
        _1_ No.
        _3_ Abstain.

9) Is Tucker's proposal as outlined above a sufficient solution to replace
the Canadian proposal?

        _4_ Yes.
        _4_ No.
        _6_ Abstain.

*************************************************************

From: Robert A. Duff
Sent: Wednesday, February 15, 2006  5:14 PM

> A feature that is solely for documentation is no better than a comment.

Pascal, I find it hard to believe that you really believe that!  I'd go so far
as to say that the _only_ important distinction between Ada and, say, assembly
language is that Ada has features whose sole purpose is to document the intent
of the programmer (as opposed to telling the machine what to do).  Such
"documentation" is far superior to comments, because it is likely true (unlike
comments).

I am in favor of the "with null" feature for this reason.
I voted against it for the Ada 2005 standard, because I think
it's too late, but (as I said before) I think the idea has
technical merit, and should be discussed as a post-Ada-2005 AI.

*************************************************************

From: Robert A. Duff
Sent: Wednesday, February 15, 2006  5:20 PM

> 1 - There is a clear consensus against changing the syntax/semantics of
> anonymous access types as proposed by the Canadian delegation.

> 8 - Tuck's 'Base idea has some appeal.

> Tuck: Prepare an AI for consideration at the Oporto meeting to allow 'Base
> for access types.

Now wait a minute!

The above seems to imply that the "with null" idea is dead in the water,
whereas the Access'Base idea is to be considered in the future.

My vote, at least, was not intended that way.  I think both ideas should not
be included in Ada 2005, but both ideas should be discussed post-2005.
And, in fact, I prefer the "with null" idea over the 'Base idea
(but I'm open minded, pending further discussion).

*************************************************************

From: Randy Brukardt
Sent: Wednesday, February 15, 2006  6:49 PM

> The above seems to imply that the "with null" idea is dead in the water,
> whereas the Access'Base idea is to be considered in the future.

Well, certainly the votes suggest that. But of course everything will be on
the table again at some future point. The only question is what to consider
*now*, as immediate AI2005's.

> My vote, at least, was not intended that way.  I think both ideas should
not
> be included in Ada 2005, but both ideas should be discussed post-2005.

Well, here I agree: both ideas should be discussed in the future, once we
have experience in the use of "not null". Right now, the way I anticipate
"not null" to be used, neither is more than a "nice-to-have". (Named
null-excluding subtypes and especially types should be rare.) But I'll be
the first to admit that I don't know how use will evolve over time.

In any case, we shouldn't be messing with Ada 2005 (other than to fix clear
bugs) before the ink is dry!

I do think there is value to having the 'Base proposal written up. And, if
you think "with null" is such a good idea, feel free to write up an AI on
it, complete with *all* of the needed wording changes. It's wouldn't hurt
for it to be on the record. But I intend to vote against any such AIs at
this time: it's just too soon to be making changes.

> And, in fact, I prefer the "with null" idea over the 'Base idea
> (but I'm open minded, pending further discussion).

This is confused, at best. Here, the vote is clear. "widening" subtypes is
not going to fly (1-10-3 is about as clear as an ARG vote ever gets). So
these two ideas are completely orthogonal to each other. (I don't understand
the vote on question 9 for that reason - but I didn't want to bias the
ballot.) 'Base is only about accessing the underlying access type that
allows null (even for a null excluding type); "with null" is pretty much
only about generic matching (it surely has nothing to do with
compatibility - the Ada 95 AI will cover that).

*************************************************************

From: Robert Dewar
Sent: Wednesday, February 15, 2006  8:40 PM

> Pascal, I find it hard to believe that you really believe that!  I'd go so far
> as to say that the _only_ important distinction between Ada and, say, assembly
> language is that Ada has features whose sole purpose is to document the intent
> of the programmer

I agree with this sentiment (and share the surprise :-)

*************************************************************

From: Robert Dewar
Sent: Wednesday, February 15, 2006  8:41 PM

> My vote, at least, was not intended that way.  I think both ideas should not
> be included in Ada 2005, but both ideas should be discussed post-2005.
> And, in fact, I prefer the "with null" idea over the 'Base idea
> (but I'm open minded, pending further discussion).

I agree with this conclusion.

*************************************************************

From: Robert A. Duff
Sent: Wednesday, February 15, 2006  8:56 PM

...
> In any case, we shouldn't be messing with Ada 2005 (other than to fix clear
> bugs) before the ink is dry!

Agreed.

> I do think there is value to having the 'Base proposal written up.

Agreed.

>..And, if
> you think "with null" is such a good idea, feel free to write up an AI on
> it, complete with *all* of the needed wording changes. It's wouldn't hurt
> for it to be on the record. But I intend to vote against any such AIs at
> this time: it's just too soon to be making changes.

Agreed -- "at this time".

> > And, in fact, I prefer the "with null" idea over the 'Base idea
> > (but I'm open minded, pending further discussion).
>
> This is confused, at best. Here, the vote is clear. "widening" subtypes is
> not going to fly (1-10-3 is about as clear as an ARG vote ever gets).

Well, I think I was one of those 10, but I think I've changed my mind.
But I'll let that slide for now, pending future (post-Ada-2005) discussion.

>... So
> these two ideas are completely orthogonal to each other. (I don't understand
> the vote on question 9 for that reason - but I didn't want to bias the
> ballot.) 'Base is only about accessing the underlying access type that
> allows null (even for a null excluding type); "with null" is pretty much
> only about generic matching (it surely has nothing to do with
> compatibility - the Ada 95 AI will cover that).

Obviously, more discussion will be needed.

*************************************************************

From: Randy Brukardt
Sent: Wednesday, February 15, 2006  9:50 PM

Seriously? Yuck. Part of the problem with "widening" with this proposal is that
it eliminates the only thing I find attractive about it: the possibility for
additional compile-time checking. I'm not interested in having a syntax that
means different things in subtypes and in parameters (after all, that's the
objection to the current rules, and it wouldn't do introduce something that has
the same problems).

*************************************************************

From: Pascal Leroy
Sent: Thursday, February 16, 2006  5:02 AM

> > A feature that is solely for documentation is no better than a
> > comment.
>
> Pascal, I find it hard to believe that you really believe
> that!  I'd go so far as to say that the _only_ important
> distinction between Ada and, say, assembly language is that
> Ada has features whose sole purpose is to document the intent
> of the programmer...

Probably a poor choice of words on my part.

Ada is about letting the programmer express her intent *AND*CHECKING* that
all usages are consistent with this intent.

My understanding of the "with null" proposal is that it doesn't involve
any legality check (but I would have to see a full-fledged AI to know for
sure).  So the only benefit you get compared with a comment is the
syntactic checking.  You could not mistype it "with nul".  Yawn.

This is exactly similar to the optional "in" for in parameters.  Do you
really believe that it brings any value?  I wish Jean had made up his mind
to either force me to write "in" or prevent me from writing "in".  The
current state of affair is ludicrous.

> I am in favor of the "with null" feature for this reason.

I am opposed to the "with null" feature for the same reason that I dislike
the situation with "in" for parameters.

*************************************************************

From: Pascal Leroy
Sent: Thursday, February 16, 2006  5:19 AM

> Now wait a minute!
>
> The above seems to imply that the "with null" idea is dead in
> the water, whereas the Access'Base idea is to be considered
> in the future.

Any idea can be considered in the future, including "out" parameters for
functions ;-)

I was not trying to manipulate the ARG in one way or another, but only to
draw the conclusions from the vote.  I only see minimal support for the
"with null" idea, and I see some interest for the 'Base idea.

So it seemed to me that it would be useful to have a write-up for 'Base,
as a basis for discussion.  Remember that I am not spending precious
meeting time on ideas for which no AI was written.  Of course, the same is
true for "with null": if you think that this is a promising idea, by all
means write an AI and I'll put it on the agenda on the next meeting (I
would actually find it useful to know what exactly is this mysterious
"with null" proposal).

Note however that we should not rock the boat and introduce new features
before the new language has got some mileage.  After all, both users and
implementers are going to be busy for some time digesting Ada 2005.

Also, it's probably the case that 'Base would be easier to introduce
incrementally in the language than "with null": features that affect the
syntax tend to be more destabilizing.

*************************************************************

From: Robert A. Duff
Sent: Thursday, February 16, 2006  6:46 AM

> Probably a poor choice of words on my part.
>
> Ada is about letting the programmer express her intent *AND*CHECKING* that
> all usages are consistent with this intent.

Right.

> My understanding of the "with null" proposal is that it doesn't involve
> any legality check (but I would have to see a full-fledged AI to know for
> sure).  So the only benefit you get compared with a comment is the
> syntactic checking.  You could not mistype it "with nul".  Yawn.

I agree -- that would be a yawn.

But I envision using a coding convention that requires "with null" in certain
well-defined cases.  And some way to automatically enforce that convention,
such as a pragma.  If we could turn back the clock, I'd then make "not null"
be the default, and eliminate the "not null" syntax.

> This is exactly similar to the optional "in" for in parameters.  Do you
> really believe that it brings any value?  I wish Jean had made up his mind
> to either force me to write "in" or prevent me from writing "in".  The
> current state of affair is ludicrous.

I agree 100% about "in".

> > I am in favor of the "with null" feature for this reason.
>
> I am opposed to the "with null" feature for the same reason that I dislike
> the situation with "in" for parameters.

Without the above-mentioned pragma, I would agree.  The pragma does not
necessarily need to be language defined.

*************************************************************

From: Pascal Leroy
Sent: Thursday, February 16, 2006  7:23 AM

> > This is confused, at best. Here, the vote is clear. "widening"
> > subtypes is not going to fly (1-10-3 is about as clear as an ARG vote
> > ever gets).
>
> Well, I think I was one of those 10, but I think I've changed
> my mind.

You must not be the real Bob Duff, you must be someone spoofing his
address.  The real Bob Duff has better taste than that.

*************************************************************

From: Robert Dewar
Sent: Thursday, February 16, 2006  7:29 AM

> Ada is about letting the programmer express her intent *AND*CHECKING* that
> all usages are consistent with this intent.

pragma Restrictions (No_Recursion) ???

so we are not 100% consistent even with this principle (there are
other examples).

Note that confirming rep clauses are really just a case of
comments for documentation as well.

> My understanding of the "with null" proposal is that it doesn't involve
> any legality check (but I would have to see a full-fledged AI to know for
> sure).  So the only benefit you get compared with a comment is the
> syntactic checking.  You could not mistype it "with nul".  Yawn.

Critically, it allows people to enforce a coding style in which the
default (which to my mind is disastrously incompatible between Ada 95
and Ada 2005) is not used at all, thus avoiding the incomaptibility.
This would be checked.

Also code using WITH NULL for a parameter would not compile in
Ada 95 mode, and the compiler *would* check this!
>
> This is exactly similar to the optional "in" for in parameters.  Do you
> really believe that it brings any value?  I wish Jean had made up his mind
> to either force me to write "in" or prevent me from writing "in".  The
> current state of affair is ludicrous.

Well any reasonable coding standard makes a choice. Certainly no
decently written Ada code mixes the two at random (see -gnatyI
in GNAT Pro for example which enforces absence of IN).

> I am opposed to the "with null" feature for the same reason that I dislike
> the situation with "in" for parameters.

The comparison is inapt. I agree with optional IN brings nothing. The
optional WITH NULL would be very valuable in managing the nasty
incompatibility between Ada 95 and Ada 2005 (I would prefer not to have
introduced such a serious (*) incompatibility, but since we did,
worrying about how to manage it is significant.

(*) to me, any change that converts legal correctly operating
programs to erroneous programs is an incompatibility of the
worst possible kind.

*************************************************************

From: Tucker Taft
Sent: Thursday, February 16, 2006  7:55 AM

We have generally had three categories, in increasing
order of unpleasantness:

   1) Incompatible, but not inconsistent
     (i.e. legal prog becomes illegal)

   2) Inconsistent, but only if predefined exeception
     had occurred originally
     (i.e. legal prog that raises predefined excep
      no longer does so)

   3) Inconsistent, including for cases where no
     predefined exception was raised
     (i.e. legal prog does something different,
      and it didn't raise an exception before)

This one seems to be in category 2.  Is there
something about it that makes it worse than
category 3, or other examples of category 2?

Also, you are using the term "erroneous" above.  Remind
me of why you say that.  Are you presuming that
some but not all null-pointer checks are being suppressed?

*************************************************************

From: Robert Dewar
Sent: Thursday, February 16, 2006  8:09 AM

> This one seems to be in category 2.  Is there
> something about it that makes it worse than
> category 3, or other examples of category 2?

I think so, see below

>
> Also, you are using the term "erroneous" above.  Remind
> me of why you say that.  Are you presuming that
> some but not all null-pointer checks are being suppressed?

I am assuming that the caller is compiled with checks on (e.g.
the normal case of an application program compiled in default
mode), and the called program has checks off (common in
libraries, where we have verified that no exceptions can
be raised).

This was the case in the GNAT run time, where we had to
make some changes because of this, although now we compile
the GNAT run time in Ada 2005 mode anyway, so that's water
under the bridge, but I can see it happening in other cases
of standard libraries.

It definitely introduces an unsafe condition that did
not exist in the Ada 95 program that was being ported.

It is one thing to remove an exception by doing something
sensible that does not cause difficulties. Here we have
removed an exception, and passed on a junk value to the
called routine which it does not expect.

That seems worse to me than say removing a CE on an
aggregate assignment because now we do proper sliding
(that's more what case 2 has in mind)

At this stage, I don't think it is feasible to fix this
incompatibility, but anything that helps deal with it is
welcome. So in order of usefulness

1. Allow NOT NULL in Ada 95 programs

2. Allow WITH NULL in Ada 2005 programs

3. Add a pragma for Ada 2005 that mandates the use of
NOT NULL or WITH NULL.

*************************************************************

From: Erhard Ploedereder
Sent: Thursday, February 16, 2006  9:04 AM

> Note that confirming rep clauses are really just a case of
> comments for documentation as well.

This is definitely, positively not true. A confirming rep clause
mandates rejection of the program, if the rep clause does not
confirm what the compiler does on its own volition. As such, it
is a very useful check of user expectation vs implementation reality.

I am struggling to imagine an example where "with null" might cause
rejection of the program. (I could see this if anon.access types were
namable.)

It it much more like the "in" parameter mode. Its presence/absence
carries zero static or dynamic semantics.

To discuss a "zero semantics" feature in the final stages of a
standardization process is a bit strange. The symmetry argument
can only carry so far....
  Type T is new Integer and not private and not limited; :-)

*************************************************************

From: Robert Dewar
Sent: Thursday, February 16, 2006  9:26 AM

> This is definitely, positively not true. A confirming rep clause
> mandates rejection of the program, if the rep clause does not
> confirm what the compiler does on its own volition. As such, it
> is a very useful check of user expectation vs implementation reality.

No, they are often used just for documentatoin


    type R is (A, B);
    for R use (A => 0, B => 1);

no rejection possible, none expected, and the rep clause is there
ONLY for documentation purposes. This actually is a fairly common
usage (Ada Magic initially forgot to special case this, and
generated junk general-case enum rep code, fixed now :-)
>
> I am struggling to imagine an example where "with null" might cause
> rejection of the program. (I could see this if anon.access types were
> namable.)

No, you have it wrong, the idea is that what you would reject (from
a tool, coding standard, possibly enforced by a pragma) is NOT
putting in WITH NULL!

That's the whole point, once you are allowed WITH NULL, you insist
on either NOT NULL or WITH NULL and do not allow the default case.

Programs written in this way are either compatible with Ada 95 and
Ada 2005, or they are illegal in Ada 95 *and will be rejected by
the Ada 95 compiler* (which is not otherwise the case).

WITH NULL may be documentation in Ada 2005, but it is (helpfully)
illegal rubbish in Ada 95.

ISO may think that Ada 95 disappears when Ada 2005 appears,
but vendors and users disagree :-)

> To discuss a "zero semantics" feature in the final stages of a
> standardization process is a bit strange. The symmetry argument
> can only carry so far....

It's not a symmetry argument. You can reject the argument, but
at least make sure you understand it! :-)

*************************************************************

From: Pascal Leroy
Sent: Thursday, February 16, 2006  8:41 AM

> pragma Restrictions (No_Recursion) ???

Not the most useful feature of the language if you ask me.  Besides,
checking is not required, but it is possible (at run-time, of course).

> Note that confirming rep clauses are really just a case of
> comments for documentation as well.

Nonono, confirming rep clauses are essential to portability.  A comment
would not have exactly the same effect.

> Critically, it allows people to enforce a coding style in
> which the default (which to my mind is disastrously
> incompatible between Ada 95 and Ada 2005) is not used at all,
> thus avoiding the incomaptibility. This would be checked.

I could be (mildly) interested by this kind of checking, but as I recall
it was not part of the Canadian proposal.  Anyway I have pretty much
gotten convinced that discussing the "with null" idea without an AI is
vacuous because we don't really know what this idea entails.

> (*) to me, any change that converts legal correctly operating
> programs to erroneous programs is an incompatibility of the
> worst possible kind.

I guess that this can happen whenever we have a change that causes a
predefined exception to be raised in a different scope than it originally
was.  I am too lazy to check the "inconsistencies" sections of the AARM,
but I'd be surprised if this were the only instance of such a change in
the Ada 83/Ada 95/Ada 2005 history.

Also, are there implementations where dereferencing the null value in
unchecked code would do something other than dumping a core?  To me, a
core dump is nearly as good as an exception for the purposes of debugging.

*************************************************************

From: Robert Dewar
Sent: Thursday, February 16, 2006  12:12 PM

> Nonono, confirming rep clauses are essential to portability.  A comment
> would not have exactly the same effect.

yesyesyes, you are missing the kind of case I am talking
about, sorry I thought it was obvious. Cases are

  type X is range - 2**31 .. + 2**31-1;
  for X'Size use 32;

  type M is (X, Y);
  for M use (0, 1);

there are other cases, I am sure you can figure out other
examples!

>>Critically, it allows people to enforce a coding style in
>>which the default (which to my mind is disastrously
>>incompatible between Ada 95 and Ada 2005) is not used at all,
>>thus avoiding the incomaptibility. This would be checked.
>
> I could be (mildly) interested by this kind of checking, but as I recall
> it was not part of the Canadian proposal.  Anyway I have pretty much
> gotten convinced that discussing the "with null" idea without an AI is
> vacuous because we don't really know what this idea entails.

OK, but you are doing the vacuuous thing, so I will continue. The
point is that even if the checking is not in the language, it is
likely their in peoples environments (for us it would be a built
in compiler style check, or a rule in our style checking tool, or both).

>>(*) to me, any change that converts legal correctly operating
>>programs to erroneous programs is an incompatibility of the
>>worst possible kind.
> I guess that this can happen whenever we have a change that causes a
> predefined exception to be raised in a different scope than it originally
> was.  I am too lazy to check the "inconsistencies" sections of the AARM,
> but I'd be surprised if this were the only instance of such a change in
> the Ada 83/Ada 95/Ada 2005 history.

I can't remember any other change I felt was this bad

> Also, are there implementations where dereferencing the null value in
> unchecked code would do something other than dumping a core?  To me, a
> core dump is nearly as good as an exception for the purposes of debugging.

My goodness, there is a blind spot there :-)
On many targets, dereferencing zero yields zero.

****************************************************************

From: Erhard Ploedereder
Sent: Thursday, February 16, 2006  12:10 PM

there is a small distinction between "exists" and "for all". You said
that "confirming rep clauses are really just a case of comments for
documentation as well." That still is plain wrong, even if you have
one example, where indeed it is. (And frankly, that particular example
reminds me of the style guide line to comment each line, resulting in
    X := X + 1;  -- increment X by 1
code.)

And hence it does not compare to the "with null" case, as you claimed
in support of your argument in favor of "with null".
That was my point, nothing more.

> It's not a symmetry argument. You can reject the argument, but
> at least make sure you understand it! :-)

I believe I do understand your proposal.

But, it did start out largely as a symmetry argument. Read the Canadian
comment, not Robert Dewar's opinion of the subject. And at this stage,
it's the Candadians that count.
No mention was made of upward compatibility arguments. Until one Robert
Dewar usurped the discussion to bend it in that direction. It was
a useful discussion, no doubt, but let us not rewrite history.

Now, as to your proposal, as soon as you appeal to tools outside the
compiler, you're entering an entirely slippery slope. The obvious
counter-argument of course is to put in special comments for your special
tool, but please don't load the language with unneeded complexity.
Especially, when you can provide a cheaper tool to once and forall change
"access T" to "access T not null" in all the right places and be done with
it, especially since you got the ACATS permission to make the "not null"
legal in Ada95.

And complexity it is, because lots of people will search the manual for
the elusive difference between
     access T with null;
and
     access T;

But, of course, you are not really appealing to a separate tool.  We can
heap still a little more complexity onto the language, by creating a pragma
that controls the need to put "with null" or "not null" in place at all
times. And, behold, the compiler now is the external tool.  And finally we
have reintroduced the feature that I believe was discussed and rejected when
the ARG dealt with "not null". Only this time it is a GNAT-defined pragma
rather than a language-defined one.
(Now I can be accused of rewriting history, too.)

****************************************************************

From: Robert Dewar
Sent: Thursday, February 16, 2006  12:22 PM

> there is a small distinction between "exists" and "for all". You said
> that "confirming rep clauses are really just a case of comments for
> documentation as well." That still is plain wrong, even if you have
> one example, where indeed it is. (And frankly, that particular example
> reminds me of the style guide line to comment each line, resulting in
>     X := X + 1;  -- increment X by 1
> code.)

Sorry, I just assumed you would realize that obviously not all
confirming rep clauses are in this category. As for the enum case,
lots of people find this a good idea, it is indeed essentially a
comment, but it is an essential one if you are interfacing with
the outside world, and much better than a comment, since it is
checked by the compiler (if you add an element without fixing the
rep clause you will get an error, but not if it were a comment).
>
> And hence it does not compare to the "with null" case, as you claimed
> in support of your argument in favor of "with null".
> That was my point, nothing more.

Seems comparable to me

> I believe I do understand your proposal.
>
> But, it did start out largely as a symmetry argument. Read the Canadian
> comment, not Robert Dewar's opinion of the subject. And at this stage,
> it's the Candadians that count.

We are talking about a new feature, I don't think there is some rule
that only the original proposers view of its advantages are allowed
to be argued!

> No mention was made of upward compatibility arguments. Until one Robert
> Dewar usurped the discussion to bend it in that direction. It was
> a useful discussion, no doubt, but let us not rewrite history.

It is not a matter of rewriting history, but merely explaining why I
think the Canadian proposal is a good idea.
>
> Now, as to your proposal, as soon as you appeal to tools outside the
> compiler, you're entering an entirely slippery slope. The obvious
> counter-argument of course is to put in special comments for your special
> tool, but please don't load the language with unneeded complexity.
> Especially, when you can provide a cheaper tool to once and forall change
> "access T" to "access T not null" in all the right places and be done with
> it, especially since you got the ACATS permission to make the "not null"
> legal in Ada95.

The cheaper tool does NOT help, please reread carefully. People are not
doing a once-and-for-all change, they do not make a sudden transition
from Ada 95 to Ada 2005, and for sure they do not want to jump off a
cliff.

> And complexity it is, because lots of people will search the manual for
> the elusive difference between
>      access T with null;
> and
>      access T;
>
> But, of course, you are not really appealing to a separate tool.  We can
> heap still a little more complexity onto the language, by creating a pragma
> that controls the need to put "with null" or "not null" in place at all
> times. And, behold, the compiler now is the external tool.  And finally we
> have reintroduced the feature that I believe was discussed and rejected when
> the ARG dealt with "not null". Only this time it is a GNAT-defined pragma
> rather than a language-defined one.
> (Now I can be accused of rewriting history, too.)

Well the ARG also rejected allowing NOT NULL in Ada 95, but now seems
inclined to change its mind.

As I said earlier, that's at least a step in the right direction.

But it does not solve the backwards forwards compatibility, which
WITH NULL + a tool does. I agree a stylized comment could be used
instead, but surely you don't think that's preferable from a language
point of view.

****************************************************************

From: Jean-Pierre Rosen
Sent: Thursday, February 16, 2006  12:39 PM

> yesyesyes, you are missing the kind of case I am talking
> about, sorry I thought it was obvious. Cases are
>
>  type X is range - 2**31 .. + 2**31-1;
>  for X'Size use 32;

This one can be confirming on one implementation, and not on another
one. It is therefore definitely useful!

****************************************************************

From: Robert A. Duff
Sent: Thursday, February 16, 2006  12:42 PM

> yesyesyes, you are missing the kind of case I am talking
> about, sorry I thought it was obvious. Cases are
>
>   type X is range - 2**31 .. + 2**31-1;
>   for X'Size use 32;

I think that's checked in the sense that Pascal is talking about.
If you accidentally wrote:

   type X is range - 2**31 .. + 2**31; -- forgot "-1"
   for X'Size use 32;

you will get an error, because X'Size = 33.

Even with the example as you wrote it, you'll get an error on a ones
complement machine.  ;-)

>   type M is (X, Y);
>   for M use (0, 1);

OK, no real checking here...

Note that this was not necessarily confirming in Ada 83, and I think the
reason it's so common is that people wanted to make sure the compiler did what
all compilers do.

In any case, I think we agree that "with null" is useless if it's not
checked.  Hence my assumption that there will be a pragma or some other way to
enforce some useful rules.  I don't care too much whether that pragma is
language defined or implementation defined.

We still need to nail down what the pragma would do.  I think there are
several choices, and the devil's in the details as usual.

Pascal and Randy suggested I write up an AI on "with null", and I will do so
someday, if I find some spare time.  But I'm in no hurry, because I'm opposed
to putting "with null" in the upcoming Ada 2005 standard, because it would
slow down the process.  Such an AI should at least propose rules for the
pragma, if not propose to add the pragma to the language.

****************************************************************

From: Robert Dewar
Sent: Thursday, February 16, 2006  5:25 PM

>>  type X is range - 2**31 .. + 2**31-1;
>>  for X'Size use 32;
>
> This one can be confirming on one implementation, and not on another
> one. It is therefore definitely useful!
>

Oops, sorry, typo, this is NEVER confirming, the confirming
declaration is of course

    for X'Size use 31;

(a size of 31 is mandated for this type)

****************************************************************

From: Robert Dewar
Sent: Thursday, February 16, 2006  5:32 PM

> I think that's checked in the sense that Pascal is talking about.
> If you accidentally wrote:
>
>    type X is range - 2**31 .. + 2**31; -- forgot "-1"
>    for X'Size use 32;
>
> you will get an error, because X'Size = 33.

chuckle, you followed my typo, you mean 31 and 32 :-)

> Even with the example as you wrote it, you'll get an error on a ones
> complement machine.  ;-)

Yes, and what about a threes complement machine. There are just as many
threes complement machines in the world as 1's complement :-)

well if you really want an example that is truly independent

type M is (X, Y)
for M'Size use 1;

(quite a common diction actually)

> In any case, I think we agree that "with null" is useless if it's not
> checked.  Hence my assumption that there will be a pragma or some other way to
> enforce some useful rules.  I don't care too much whether that pragma is
> language defined or implementation defined.

We do *NOT* agree on this at all, for two reasons.

1) it is perfectly useful to have coding standards which are not checked
by tools. You don't need a policeman there to make you behave :-)

2) completely different point. It is useful to be able to write an Ada
2005 program which works only in Ada 2005, which will not compile if
you try it on an Ada 95 compiler.

By following the rule of using WITH NULL always, you make sure that your
Ada 2005 program which will not run properly on Ada 95 will be rejected
by an Ada 95 compiler.

Without the change, you end up with a program that is legal in Ada 95
and Ada 2005, and there is no indication in the program text that this
is an Ada 2005 program only.

****************************************************************

From: Pascal Leroy
Sent: Friday, February 17, 2006  3:14 AM

> >>  type X is range - 2**31 .. + 2**31-1;
> >>  for X'Size use 32;
>
> Oops, sorry, typo, this is NEVER confirming, the confirming
> declaration is of course
>
>     for X'Size use 31;
>
> (a size of 31 is mandated for this type)

Wow!  If you manage to squeeze this type on 31 bits, you must use an
impressive compression algorithm.  Is it related to US patent 5,533,051?
(Details at http://gailly.net/05533051.html.)

****************************************************************

From: Robert Dewar
Sent: Friday, February 17, 2006  1:34 PM

Can't believe it, well I certainly don't want to treat on
any patent, especially one as impressive as this, so I
withdraw my implicit suggestion that we incorporate this
patent into the design of Ada 2015 (I think it would be
too late for 2005 anyway) :-) :-)

****************************************************************

From: Pascal Leroy
Sent: Friday, February 17, 2006  2:54 AM

> >   type M is (X, Y);
> >   for M use (0, 1);
>
> OK, no real checking here...

That's what was claimed by one instance of Robert Dewar, but another
instance of Robert Dewar cleverly pointed out that it's not true.  If,
during maintenance, you add a new enumeration literal to type M, the
compiler is going to draw your attention to the enumeration representation
clause.  This is especially important if the new literal is not added at
the end of the type: in the absence of a clause, the representations would
just shift silently.

Confirming representation clauses are very useful for maintenance: in many
cases the compiler will flag those changes to the type that may affect the
representation

****************************************************************

From: Robert Dewar
Sent: Friday, February 17, 2006  5:17 AM

> Confirming representation clauses are very useful for maintenance: in many
> cases the compiler will flag those changes to the type that may affect the
> representation

Indeed. I actually think that there should be a rule that the
compiled accept all confirming representation clauses, which
is not necessarily the case.

However, with only the attributes in the RM, you actually cannot
write a full set of confirming rep clauses anyway (because you
cannot control size of subtypes, or object sizes -- that's why
we added the attributes Object_Size and Value_Size to GNAT).

****************************************************************

From: Robert Dewar
Sent: Friday, February 17, 2006  5:21 AM

> That's what was claimed by one instance of Robert Dewar, but another
> instance of Robert Dewar cleverly pointed out that it's not true.

Actually, the two Dewar's are consistent here. On the one hand, the
rep clause serves no purpose, since it is just a comment, but in a
maintenance context it is useful.

That's actually my analogy with WITH NULL. On its own in an Ada 2005
program, it serves no purpose other than documentation, but in a
maintenance context it certainly does get checked if you try to
compile in Ada 95 mode, and it might get checked bya pragma or
tool.

Just to be clear, I don't see adding WITH NULL at this late stage
given no clear support. I would like to see allowing NOT NULL in
Ada 95 (in fact we just made this change -- again -- in GNAT) and
we will cough up some NOT-NULL'ing tool, and perhaps a style check
requiring the use of NOT NULL in Ada 95 mode.

P.S. regarding pragmas that enforce style checking type stuff, I
was surprised to see that the pragma for overriding had disappeared,
so I assumed that the ARG had somewhat decided that such pragmas
did not belong in the official language anyway.

****************************************************************

From: Pascal Leroy
Sent: Friday, February 17, 2006  6:34 AM

> Indeed. I actually think that there should be a rule that the
> compiled accept all confirming representation clauses, which
> is not necessarily the case.

There is actually an IA to that effect in Ada 2005, see 13.1(21.1).  Of
course, with dope and dynamic stuff and so on this cannot be a
requirement.  But this IA is intended to nudge implementers in the right
direction.

[This thread became AI05-0009-1, and the mail continues there. - Editor]

From: Randy Brukardt
Sent: Friday, February 17, 2006  2:36 PM

> But I envision using a coding convention that requires "with null" in certain
> well-defined cases.  And some way to automatically enforce that convention,
> such as a pragma.  If we could turn back the clock, I'd then make "not null"
> be the default, and eliminate the "not null" syntax.

I miss a day due to a snowstorm, and people lose their minds. :-)

I can't begin to imagine why you would think making "not null" the default
would be a good idea. (It was a lousy idea in Ada 95, and it still is.)
-- Ada doesn't allow widening of types, so the least restrictive type
   needs to be the root (and default);
-- We surely don't want the semantics of parameters and named types to
   differ;
-- "not null" is inappropriate for most general uses; usually, you need
   an indication of "no object" -- the default should be the most common
   use -- even for parameters, the need to be able to pass "no object"
   is common (see interfacing to C, for one example).

I can see some value to the "with null" proposal, presuming it adds some
compile-time checking. But I don't see any point in adding something solely
for the benefit of external tools.

In any case, if you think this is important, write up an AI so we have
something specific to discuss. As it is, there seems to be as many ideas of
what this should mean as there are ARG members, and we're wasting a lot of
time because of it.

****************************************************************

From: Robert Dewar
Sent: Friday, February 17, 2006  2:41 PM

> I can't begin to imagine why you would think making "not null" the default
> would be a good idea. (It was a lousy idea in Ada 95, and it still is.)

Perhaps because he has *not* lost his mind and still remembers that
upwards compatibility is a NUMBER ONE priority in designing new features.

You simply do not have the luxury of fixing things at this expense.

> -- Ada doesn't allow widening of types, so the least restrictive type needs
> to be the root (and default);

I don't see that argument

> -- We surely don't want the semantics of parameters and named types to
> differ;

why not? they were different in Ada 95, maybe it was a mistake, but it
is a mistake we should live with.

> I can see some value to the "with null" proposal, presuming it adds some
> compile-time checking. But I don't see any point in adding something solely
> for the benefit of external tools.

er hum! Hate to repeat myself, but unless you think of the Ada compiler
as an external tool, then this is NOT just for the benefit of Ada tools.
An important part of WITH NULL is that it allows you to write a program
that assumes Ada 2005 semantics in a manner that will cause it (like many
other Ada 2005 extensions) to be rejected by an Ada 95 compiler.

****************************************************************

From: Randy Brukardt
Sent: Friday, February 17, 2006  3:37 PM

...
> Perhaps because he has *not* lost his mind and still remembers that
> upwards compatibility is a NUMBER ONE priority in designing new features.
>
> You simply do not have the luxury of fixing things at this expense.

Let me remind you that we originally designed a change that had exactly this
property.

But the Ada users who reviewed the proposal found it distasteful, and felt
that the incompatibility was better than the alternatives. We decided to
follow the users in this case. I can only recall one other instance where we
changed a proposal because of strong user comments - it's not something that
we've done lightly.

It's of course interesting that the strongest user voices were at AdaCore.

Now, with additional experience/information/whatever, we might make another
decision.

In any case, the WG 9 instructions were quite clear that compatibility,
while a high priority, is not the only such consideration. Making/keeping
the language consistent, for instance, also enters into the equation. I
think we were pretty conservative about accepting incompatibilities. You can
disagree with the WG 9 instructions, but it's a little late (about 5 years)
to be complaining about that.

****************************************************************

From: Robert Dewar
Sent: Friday, February 17, 2006  3:55 PM

> But the Ada users who reviewed the proposal found it distasteful, and felt
> that the incompatibility was better than the alternatives. We decided to
> follow the users in this case. I can only recall one other instance where we
> changed a proposal because of strong user comments - it's not something that
> we've done lightly.

Harumph! What's the ARG methodology for choosing representative users
to review proposals? I suspect there is none, and that you are really
reacting to an online community of enthusiasts, who do not represent
real Afda users.
>
> It's of course interesting that the strongest user voices were at AdaCore

singular please, one person, and I assure you we have NO users at
AdaCore, only enthusiasts. Franco would be the first to say that he
is not representative of the Ada user community, except by proxy.
Of course that's the same status that ARG users have. I agree that
input from real users would be a great idea.

> Now, with additional experience/information/whatever, we might make another
> decision.
>
> In any case, the WG 9 instructions were quite clear that compatibility,
> while a high priority, is not the only such consideration. Making/keeping
> the language consistent, for instance, also enters into the equation. I
> think we were pretty conservative about accepting incompatibilities. You can
> disagree with the WG 9 instructions, but it's a little late (about 5 years)
> to be complaining about that.

Making the language consistent is important, but it's secondary. After
all we managed to live with an inconsistency here for ten years without
any significant complaints.

Yes, people did complain about the NOT NULL semantics of access
parameters (as well they might, it was a clear design error in my
view). But I never heard users complaining about the inconsistency.

Now of course, we have introduced anonymous access types into Ada 2005,
and yes, it is important that they be consistent with parameters, but
I see no compelling argument for consistency at any other level.

The right thing to do would have been to assume NOT NULL by default in
both cases for compatibility with Ada 95, and allow WITH NULL to specify
that null was allowed.

But please note that my position at this stage is that as long as we
allow NOT NULL in Ada 95, we are not in too terrible a position. The
thing that really upset me was removing this useful decision. At least
it seems we may get that back as a result of this discussion, which
means that the Canadian proposal, while it has not got enough support
to fix the problem, has at least resulted in alleviating the problem.

****************************************************************

From: Tucker Taft
Sent: Friday, February 17, 2006  4:06 PM

> ...
> The right thing to do would have been to assume NOT NULL by default in
> both cases for compatibility with Ada 95, and allow WITH NULL to specify
> that null was allowed.

Robert, you do have a way of making pronouncements! ;-)

We certainly debated this long and hard in the ARG, and we did
our best to consider both existing and future users of Ada 2005.
We came to a different conclusion, and personally, I believe
it was the right thing for the language.  Your mileage may vary...

****************************************************************

From: Robert Dewar
Sent: Friday, February 17, 2006  5:42 PM

Well I call things as I see them :-) In this case I think it would
have been a good idea to get some systematic input from real users.
Well hopefully in practice I am too worried about the problem, and
no one will notice the incompatibility!

I guess I just take upwards compatibility as a much more important
and absolute requirement. For sure this will make it harder to sell
Ada 2005, though the ability to use NOT NULL in Ada 95 will in
practice help a lot, and probably be sufficient to deal with the
problem.

****************************************************************

From: Robert A. Eachus
Sent: Saturday, February 18, 2006  9:05 PM

Amen.  I just talked to someone about a ride to church tomorrow, and
explained that I sounded frustrated, by this discussion.  I said
something like:  "All of the proposed fixes will be studied.  Eventually
the ARG will stop playing WG9 level politics and recommend the right
technical fix..."

I think we have to stop playing at being WG9, and do the job of the ARG.

To sum up huge numbers of posts:

Is there something here that is broken?
     Well, er, sort of, maybe, yeah, but not too badly.
Should it be fixed?
     Not if it delays the new standard.
I didn't ask you that.  Should it be fixed?
     Maybe.
How should it be fixed?
     Well, er, uh.  Let me get back to you on that.

Robert Dewar's point, that allowing the *non null *notation in Ada 95
reduces the severity of the issue is the sort of thing that belongs in
an ARG discussion.  But the major issue in this discussion seems to be
whether the issue is important enough to hold up the standard.  That is
an important question to answer, and we should be giving WG9 what advice
we can about that.  But WG9 should be the ones making the final
decision--even when it is the same people.

As I see it there are several positions the ARG can take on the Canadian
proposal:

1) There is no serious problem with the current draft standard.  The
Canadian proposal is a nice to have, but way too late.  (Note that in
this situation, and only if there is no serious issue, does the ARG
opinion on timeliness matter.)

2) There is a problem, and here is our best technical proposal for
fixing it.  If the problem is serious, then a rejection or even yes with
comments votes at the WG9, SC22, or JTC1 level could delay things much
more than taking the time to find the right fix now.  (IMHO, the
Canadian proposal identifies a problem, but certainly their proposed
repair needs a lot of detailed work. That is the ARG's job, though.)

3) There is a problem, but it is minor and we suggest fixing it either
in the next version of the standard or a Corrigendum.

I think choice 3) is right out.  The problem identified is most serious
in Ada 95 to Ada 2005 migration. Even if it wasn't, a second
incompatable change would be right out, so we had better get it right
right now. I have become convinced that the first possibility is also
out.  Do I think that allowing non null  in Ada 95 is a complete
solution?  No, it might be enough of an answer to allow us to move
forward, but there is another issue I see.

The problem that I now see is that a lot of ARG members have this magic
concept of annonymous access types.  What is the magic?  That the base
type of such access types does not include null.  In Ada 95 as I see it,
this was not a big issue.  If you squinted just right, annonymous access
types were separate from named access types, so there was no issue.  But
as I see it, in Ada 2005, this viewpoint doesn't work.  You can convert
from a named access type to an anonymous access type.  A necessary and
useful feature.  But we now run into the issue that Tucker accidently
identified with his 'Base proposal:

Compilers are expected to translate from named types to anonymous access
parameters with low or no overhead, in practice most base types will
actually be the same.  But converting from a null-including subtype to a
null-excluding subtype will imply a check.  So far, so good.  But what
happens when that check is suppressed?

Robert Dewar's post about compiling the Ada Core run-time suddenly
started ringing alarm bells, especially when put together with the
discussion of 'confirming' rep clauses.  Much as I would like to say
otherwise, I think that if you use an explicit *non null *subtype for
passing parameters, that had better be checked--even if this implicitly
overrides pragma Suppress.  Now, *with null *Foo, or Tucker's Foo'Base
has real semantics, including the reverse check in function returns and
*in out* parameters.  Is it necessary semantics to support in Ada 2005?
I don't know.  I do know that it will be extremely useful when writing
thin bindings to libraries or operating systems  in C.

This may be why I was the only one who seemed to think that Foo'Base
possibly had more values than the first named subtype in "*type* Foo *is
non null access* Bar;"  Certainly we all know that the arithmetic
operators are now written in the RM with 'Base to make it clear that
they do not check the subtypes on call or return. I thought everyone
here realized that Foo above is a subtype of an anonymous type, and
Foo'Base, if added to the language would allow users to name that type.
It is not a subtype with more values than it's parent type, just the
name of the parent type.

In any case, I think we do need to deal with the real issue here, which
is not the syntax--I can live with *with null*, *accept null*, or
'Base.  The real question is whether we need to allow programmers to
specify what they expect?  I think we do, in fact, from some of the
discussion here, it is clear that if we don't get it right, we can't
expect compiler writers--most of whom are represented here to figure out
where to put the checks for null, and when it is okay to omit them.

****************************************************************


Questions? Ask the ACAA Technical Agent