!standard  3.10      (06)                        01-10-01  AI95-00231/02
!standard  3.10      (12)
!standard  4.6       (49)
!standard  8.6       (25)
!class amendment 00-04-13
!status work item 00-04-13
!status received 00-04-13
!priority Medium
!difficulty Hard
!subject Access-to-constant parameters and null-excluding subtypes

!summary

Parameters and discriminants of an anonymous access-to-constant type are
introduced. Access parameters and access discriminants are generalized
to have a variant that allows a null value. Null-excluding subtypes of
a named access type are introduced.

!problem

(See discussion.)

!proposal

Introduce a not-null constraint, and an access_constraint syntactic category.

Modify 3.2.2(5) to:
    constraint ::= scalar_constraint | access_constraint | composite_constraint

    access_constraint ::=
       not_null_constraint | composite_constraint [not_null_constraint]

Modify 3.10(6) to:

    not_null_constraint ::= NOT NULL

    access_definition ::=
       ACCESS ALL subtype_mark [not_null_constraint]
     | ACCESS CONSTANT subtype_mark [not_null_constraint]
     | ACCESS subtype_mark

Modify 3.10(12) to:

    An access_definition defines an anonymous general access type; the subtype
    mark denotes its @i<designated subtype>. If the word @b<all> appears, the
    type is an access-to-variable type. If the word @b<constant> appears, the
    type is an access-to-constant type. If the words @b<not null> appear, the
    access_definition defines an access subtype which excludes the null
    value. If neither @b<all> nor @b<constant> appear, the access definition is
    equivalent to having both @b<all> and @b<not null> present, and hence
    defines an access-to-variable subtype that excludes the null value. An
    access_definition is used in the specification of an access discriminant
    (see 3.7) or an access parameter (see 6.1).

Drop the parenthetical "(named)" from the first sentence of 3.10(13), since in
our new model, anonymous access types have a null value, even though a subtype
might exclude the null value.

Modify 3.10(15), to:
    An access_constraint includes a not_null_constraint, a
    composite_constraint, or both. An access_constraint with a
    composite_constraint is compatible with an unconstrained access subtype if
    the composite_constraint is compatible with the designated subtype. An
    access_constraint with a not_null_constraint is compatible with an access
    subtype if the subtype includes a null value. An access value satisfies a
    composite_constraint imposed on an access subtype if it equals the null
    value of its type or if it designates an object whose value satisfies the
    constraint.  An access value satisifes a not_null_constraint imposed on an
    access subtype if it does not equal the null value of its type.

Delete paragraph 4.1.4(7) which says that anonymous access types don't
have a null value.

Modify 4.6(49) to:
    If the target subtype excludes the null value, then a check is made that
    the value of the operand is not null; if the target subtype includes null,
    then the result of the conversion is null if the operand value is null.

Modify 8.6(25) so that implicit conversion to any anonymous access type is
permitted, with the expected rules (i.e. it is illegal to convert an
access-to-constant to access-to-variable).

!wording

(See proposal.)

!example


!discussion

It is surprising that an access-to-constant parameter/discriminant is
not available. There are several circumstances where such a
parameter/discriminant would be appropriate:

   As a controlling parameter of an operation that doesn't modify the
      designated object.
   As a way to force pass-by-reference when interfacing with a foreign
      language, when the external operation does not update the designated
      object,
   As a way to provide read-only access via a discriminant.

The rule disallowing "null" for access parameters and access discriminants has
turned out to be confusing, and not what is wanted in all cases when
interfacing with a foreign language. Therefore, we propose to define an
explicit way to exclude nulls from an access subtype, make "access all T" and
"access constant T" includes nulls by default, but for backward compatibility
make "access T" a shorthand for "access all T not null."

The general ability to specify an access subtype that excludes null for both
named and anonymous access types can provide useful documentation and higher
efficiency. This is especially true for parameters, by allowing the nullness
check to be "pushed" to the caller, where it can be more likely removed.

What should be the default initialization of an object of a subtype that
excludes null? It seems clear that the default is still null, and the
initialization will raise Constraint_Error. Hence, objects of such a subtype
will require explicit initialization. Perhaps a NOTE to this effect should be
included in 3.10.

!appendix

Randy Brukardt  00-04-13

This proposal was split out of the "with type" proposal (AI-00217) in
April 2000. Some early conversation on this feature can be found in that
AI's appendix.

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