!standard 6.3.1 (15) 06-01-06 AI95-00409/05 !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{.} {If the anonymous access type is}[which in the case of] an access-to-object type shall have the same designated type as that of the access_definition{. If the anonymous access type is}[ 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) and make it a separate paragraph: ... 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) @dinsa @xbullet for an entry.> @dinst @xbullet if the reserved word @b appears in its definition and otherwise is the convention of the subprogram that contains the parameter.> !corrigendum 6.3.1(15) @drepl Two profiles are @i 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. @dby Two profiles are @i 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) @drepl Two profiles are @i if they are type-conformant, and corresponding parameters have identical modes, and, for access parameters, the designated subtypes statically match. @dby Two profiles are @i 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) @dinsa @xcode<@fa@ft<@b>@fa< object_name;>> @dinst The @fa shall not include a @fa. !corrigendum 8.5.1(3) @drepl The type of the @i@fa shall resolve to the type determined by the @fa. @dby The type of the @i@fa shall resolve to the type determined by the @fa, or in the case where the type is defined by an @fa, to an anonymous access type. If the anonymous access type is an access-to-object type, the type of the @i@fa shall have the same designated type as that of the @fa. If the anonymous access type is an access-to-subprogram type, the type of the @i@fa shall have a designated profile that is type conformant with that of the @fa. !corrigendum 8.5.1(4) @dinsa The renamed entity shall be an object. @dinss In the case where the type is defined by an @fa, the type of the renamed object and the type defined by the access_definition: @xbullet @xbullet !corrigendum 8.5.1(6) @drepl An @fa 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 @fa. 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 @fa of the @fa is ignored). @dby An @fa 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 @fa. 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 @fa of the @fa is ignored). !corrigendum 8.6(25) @drepl @xinbull is an anonymous access type (see 3.10) with designated type @i, to an access-to-variable type whose designated type is @i'Class or is covered by @i.> @dby @xinbull is a specific anonymous access-to-object type (see 3.10) with designated type @i, to an access-to-object type whose designated type is @i'Class or is covered by @i; or> @xinbull is an anonymous access-to-subprogram type (see 3.10), to an access-to-subprogram type whose designated profile is type-conformant with that of @i.> !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. ************************************************************* From: Tucker Taft Sent: Monday, January 2, 2006 8:15 PM It seems odd that paragraph 8.5.1(4/1) combines the following: 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: * shall both be blah blah; or * shall both be blah blah. Wouldn't it make more sense for the second sentence to start its own paragraph? It seems to have almost nothing to do with the first sentence. *************************************************************