Version 1.2 of ais/ai-00409.txt

Unformatted version of ais/ai-00409.txt version 1.2
Other versions for file ais/ai-00409.txt

!standard 6.3.1 (15)          05-02-07 AI95-00409/01
!class amendment 05-02-07
!status work item 05-02-07
!status received 05-02-07
!priority High
!difficulty Easy
!subject Conformance and overload resolution related to anon access types
Type conformance requires access-to-subp access parameters to have type conformant designated profiles. For mode conformance, access-to-subp access parameters should have subtype conformant designated profiles and matching convention (e.g. protectedness). For subtype conformance, subtypes of corresponding access parameters should statically match. Null-exclusion must match for subtype conformance, but need not match for mode conformance.
Overload resolution should be based on type conformance. Legality rules should enforce mode or subtype conformance, as appropriate.
The overloading and conformance rules relating to anonymous access-to-subprogram types are not consistent with the rest of the language. In particular, overloading distinctions are made on the basis of subtype conformance of designated profiles between the actual parameter and the formal parameter. This should be relaxed to be based on type conformance, and legality rules added as necessary to ensure subtype conformance. This is relevant for resolution on renaming of an object of an anonymous access-to-subp type, as well as on assignment.
Change 6.3.1(15):
... or, for access parameters, corresponding designated types are the same{, or corresponding designated profiles are type conformant}.
Change 6.3.1(16/2):
... and, for access parameters or access result types, the designated subtypes statically match{, or the designated profiles are subtype conformant}.
Disallow explicit specification of null exclusion in renaming, by adding a syntax rule after 8.5.1(2/2):
The access_definition shall not include a null_exclusion.
Replace last part of 8.5.1(3/2):
... or in the case where the type is defined by an access_definition, to an anonymous access type with the same designated type or designated profile that is type conformant with that of the access_definition.
Replace last part of 8.5.1(4/2)
... In the case where the type is defined by an access_definition, the type of the renamed object and the type defined by the access_definition shall have statically matching designated subtypes, or subtype conformant designated profiles. For the anonymous access-to-object case, the two types shall either both or neither be access-to-constant types.
Explicit null_exclusion is not permitted. Null exclusiveness need not match, in the same way that constraints need not match, and "constant" is not specified. The renaming defines a view of the renamed entity, inheriting the original properties.
Change 8.5.1(6/2):
... similarly, the {null exclusion or} constraints that apply ...
Remove from 8.6(25/2):
... [, and that is access-to-constant only if T is access-to-constant.]
Change 8.6(25.1/2):
... whose designated profile is [subtype]{type}-conformant with that of T.
The originally proposed name resolution rules don't correspond to "type conformant" vs. "mode conformant" vs. "subtype conformant". Type conformance determines whether two overloadables are considered homographs, and it seems a little funny for the expected type rules for individual parameters to go significantly beyond what determines type conformance for the profile as a whole. For example, 25.a/2 indicates that these rules allow distinguishing between two subprograms where one has an access-to-constant param, and the other has an access-to-variable param. Do we really want that to be a basis for overload resolution? The old rule was distinguishing between a named access-to constant and an anonymous access-to-variable. Do we really want to distinguish between an anonymous access-to-constant and an anonymous access-to-variable? That seems like distinguishing between IN and IN OUT during name resolution, which is considered a bad idea, because ambiguity is being resolved in what might very well be an unexpected or accidental way.
In general, expected type resolution rules shouldn't be much pickier than that associated with type conformance between subprogram profiles. In fact, they tend to be looser than type conformance, in that they allow T'Class to match T, etc.
So whatever we decide here ought to correlate well with what we decide for type conformance. As suggested above, probably the expected type should resolve anonymous access-to-subp operands based on type conformance, rather than subtype conformance. That seems more consistent with resolving anon access-to-object based on designated type rather than subtype. They should also not consider acc-to-constant vs. acc-to-variable for anonymous access types. Also, since presumably a value of an access-to-variable type can be implicitly converted to an anonymous access-to-constant type, it doesn't seem to make sense to consider that during expected type resolution.
!ACATS test


Questions? Ask the ACAA Technical Agent