Version 1.1 of ais/ai-00389.txt

Unformatted version of ais/ai-00389.txt version 1.1
Other versions for file ais/ai-00389.txt

!standard 4.3.1(8)          04-11-11 AI95-00389/01
!class amendment 04-11-11
!status work item 04-11-11
!status received 04-11-11
!priority Medium
!difficulty Medium
!subject Allow aggregates of partial views
An aggregate of a partial view is allowed; such an aggregate must contain "others => <>" to default initialize the components only known to the full view.
AI95-00287 introduces the <> (box) notation for default initializing components of an aggregate. This can be used on any type. However, aggregates of a partial view (which is considered to be a composite type) are not allowed. Default-initialized aggregates of a partial view should be allowed.
Default-initialized aggregates are especially useful to define constants (which are required to be initialized) outside of the defining package of a private type. They also can be useful to explicitly show that the default initialization of an object is intended and important to proper functioning of a program.
Allow record aggregates to be of a partial view. The needed components still are those of the full view, even though the components of the full view cannot be named. An aggregate of a partial view must include "others => <>"; this is needed to avoid any dependence on the components of the full view.
Note that if known discriminants are given for the type, they can be specified along with "others => <>".
The wording of this AI assumes the wording changes of AI-287 have been applied.
Change 4.3.2(8):
The expected type for a record_aggregate shall be a single record type, record extension, or partial view of a type.
4.3.2(9) is unchanged. Add additional AARM notes to the end of the paragraph:
Ramification: For a partial view, all of the components of the full type are needed, even though not all of them can be named in the aggregate.
To Be Honest: If the full view of the type is not composite, it is thought of as a record containing one component of the full type.
Modify the start of 4.3.2(16) to:
Each record_component_association {other than an OTHERS choice without an expression} shall have at least one associated component...
Modify the AARM Note 4.3.2(16.a): These rules apply to an association with an others choice {with an expression}. {An others choice without an expression can match a null record type or a null extension.}
[Author's Note: This is needed so that an others choice for a partial view can match a null record full type. This is required so that we don't "leak" information about the full type to the uses. I believe that this is really a bug in AI-287 anyway; a default-initializing others should be allowed to match nothing, as it is harmless (by using OTHERS you've turned off completeness checking anyway) and useful.]
Add after 4.3.2(17.1): (The new Legality Rule added by AI-287)
If the aggregate denotes a partial view of a type, then the aggregate shall include OTHERS => <>.
AARM Note: This is needed to avoid "leaking" information about the full type to the aggregate. Without this rule, if the full type was NULL RECORD, NULL RECORD could be used; and if the full type had only one component, OTHERS => some-expression could be used. That would clearly break privacy. Since each component can only occur in a single association, this rule prevents those issues.
If the aggregate denotes a partial view of a type, then the aggregate shall not have unknown discriminants.
AARM Note: Unknown discriminants are often used to prevent uncontrolled initialization of objects, and we don't want to provide an uncontrolled initialization mechanism for such types.
This capability is a natural extension to that provided by AI-287. It is especially odd that such initializations are allowed in larger aggregates, just not for a complete object. For instance, given that Priv is a private type:
type Wrapper is record P : Priv; end record;
Obj1 : constant Priv := (others => <>); -- Illegal by AI-287, allowed here. Obj2 : constant Wrapper := (others => <>); -- Legal by AI-287.
We have chosen not to define extension aggregates for partial extensions. These would have implementation issues, and for the most part duplicate functionality of record aggregates for partial views.
Implementing an extension aggregate of a partial view would require a mechanism to default-initialize only the extension part of a type. This would be a new capability; while Ada compilers routinely have to default-initialize entire objects of a type (optionally with specified discriminants), they don't have to do that for a portion of a type (except for constructing the default-initialization of a containing type). This would be especially messy for type derived from a generic formal derived type, as the details of the extension parts would come from the actual type.
Moreover, an extension aggregate of a partial extension using a subtype ancestor is identical in meaning to a record aggregate of the same type. That is (Some_Parent with others => <>) is just a complicated way to say (others => <>), since the Some_Parent part is also default initialized.
We do lose the capability to initialize the parent part with an expression for a partial view, but this ability doesn't seem to be worth the implementation burden.
(See discussion.)
!ACATS test
ACATS tests need to be constructed to check that aggregates of partial views are allowed and allow the inclusion of discriminant values.


Questions? Ask the ACAA Technical Agent