Version 1.4 of ais/ai-00409.txt

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

!standard 6.3.1 (15)          05-06-15 AI95-00409/03
!standard 6.3.1 (16)
!standard 8.5.1 (2)
!standard 8.5.1 (3)
!standard 8.5.1 (4)
!standard 8.6 (25)
!class amendment 05-02-07
!status Amendment 200Y 05-03-09
!status ARG Approved 8-0-2 05-02-13
!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
!summary
Type conformance requires access-to-subprogram access parameters to have type conformant designated profiles. For mode conformance, access-to-subprogram 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.
!problem
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-subprogram type, as well as on assignment.
!wording
Change the paragraph added after 6.3.1(13) by AI-254 to:
The calling convention for an [access]{anonymous access-to-subprogram} parameter {or anonymous access-to-subprogram result}[of an access-to-subprogram type] is protected if the reserved word protected appears in its definition and otherwise is the convention of the subprogram that contains the parameter.
Change 6.3.1(15):
... or, for access parameters {or access results}, corresponding designated types are the same{, or corresponding designated profiles are type conformant}.
Change 6.3.1(16) (as modified by AI-318-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):
The access_definition shall not include a null_exclusion.
Change the last part of 8.5.1(3) (as modified by AI-230 and AI-254):
... or in the case where the type is defined by an access_definition, to {an}[a specific] anonymous access type{,} which in the case of an access-to-object type shall have the same designated type as that of the access_definition{,} and in the case of an access-to-subprogram type shall have a designated profile {that}[which] is [subtype]{type} conformant with that of the access_definition.
Replace last part of 8.5.1(4) (as modified by AI-231):
... 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 both be access-to-object types with statically matching designated subtypes and with both or neither being access-to-constant types; or
* shall both be access-to-subprogram types with subtype conformant designated profiles.
Change 8.5.1(6):
... similarly, the {null exclusion or} constraints that apply ...
AARM NOTE:
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.
Remove from 8.6(25) (as modified by AI-230, AI-231, and AI-254):
... [, and that is access-to-constant only if T is access-to-constant]; or
Change the paragraph assed after 8.6(25) by AI-254:
... whose designated profile is [subtype]{type}-conformant with that of T.
!discussion
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-subprogram 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 access-to-constant vs. access-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.
!corrigendum 6.3.1(13)
Insert after the paragraph:
the new paragraph:
!corrigendum 6.3.1(15)
Replace the paragraph:
Two profiles are type conformant if they have the same number of parameters, and both have a result if either does, and corresponding parameter and result types are the same, or, for access parameters, corresponding designated types are the same.
by:
Two profiles are type conformant if they have the same number of parameters, and both have a result if either does, and corresponding parameter and result types are the same, or, for access parameters or access results, corresponding designated types are the same, or corresponding designated profiles are type conformant.
!corrigendum 6.3.1(16)
Replace the paragraph:
Two profiles are mode conformant if they are type-conformant, and corresponding parameters have identical modes, and, for access parameters, the designated subtypes statically match.
by:
Two profiles are mode conformant if they are type-conformant, and corresponding parameters have identical modes, and, for access parameters or access result types, the designated subtypes statically match, or the designated profiles are subtype conformant.
!corrigendum 8.5.1(2)
Insert after the paragraph:
object_renaming_declaration ::= defining_identifier : subtype_mark renames object_name;
the new paragraph:
The access_definition shall not include a null_exclusion.
!corrigendum 8.5.1(3)
Replace the paragraph:
The type of the object_name shall resolve to the type determined by the subtype_mark.
by:
The type of the object_name shall resolve to the type determined by the subtype_mark, or in the case where the type is defined by an access_definition, to an anonymous access type, which in the case of an access-to-object type shall have the same designated type as that of the access_definition, and in the case of an access-to-subprogram type shall have a designated profile that is type conformant with that of the access_definition.
!corrigendum 8.5.1(4)
Replace the paragraph:
The renamed entity shall be an object.
by:
The renamed entity shall be an object. 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:
!corrigendum 8.5.1(6)
Replace the paragraph:
An object_renaming_declaration declares a new view of the renamed object whose properties are identical to those of the renamed view. Thus, the properties of the renamed object are not affected by the renaming_declaration. In particular, its value and whether or not it is a constant are unaffected; similarly, the constraints that apply to an object are not affected by renaming (any constraint implied by the subtype_mark of the object_renaming_declaration is ignored).
by:
An object_renaming_declaration declares a new view of the renamed object whose properties are identical to those of the renamed view. Thus, the properties of the renamed object are not affected by the renaming_declaration. In particular, its value and whether or not it is a constant are unaffected; similarly, the null exclusion or constraints that apply to an object are not affected by renaming (any constraint implied by the subtype_mark of the object_renaming_declaration is ignored).
!corrigendum 8.6(25)
Replace the paragraph:
by:
!ACATS test
!appendix

From: Bob Duff
Sent: Monday, June 6, 2005  12:39 PM

I'm using draft 11.8 of the [A]ARM.

6.3.1(13.1/2):

13.1/2 {AI95-00254-01} {AI95-00409-01} The calling convention for an access
      parameter or access result of an access-to-subprogram type is protected
      if the reserved word protected appears in its definition and otherwise
      is the convention of the subprogram that contains the parameter.

I had to read that several times to understand it.  At first I thought it meant
we have an access-to-subprogram type, and it has an access parameter, and this
is defining the calling convention of that parameter -- but parameters don't
have calling conventions.  E.g.:

    type T is access procedure(X: access Integer);

I thought it was talking about the calling convention of X.

How about changing "of an access-to-subprogram type" to "whose type is an
access-to-subprogram type"?

Or perhaps say: "an access-to-subprogram parameter or result...".

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

From: Randy Brukardt
Sent: Monday, June 6, 2005  10:08 PM

The latter unfortunately seems to mean any access-to-subprogram parameter,
and we don't mean that (only anonymous ones) so that's out. The former
works, but makes ugly wording even uglier. We generally call the "anonymous
access-to-subprogram parameters" to avoid confusion (even though its very
wordy). But I worry that its not clear that all of the adjectives apply to
result; it seems to be hanging out there without a clear association.

   The calling convention for an anonymous access-to-subprogram parameter or
   anonymous access-to-subprogram result is protected if the reserved word
protected
   appears in its definition and otherwise is the convention of the
   subprogram that contains the parameter.

That seems better, and isn't much longer than the original.

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

From: Pascal Leroy
Sent: Tuesday, June 7, 2005  4:15 AM

Agreed.

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


Questions? Ask the ACAA Technical Agent