Version 1.8 of ais/ai-00397.txt
!standard 6.3.1(24) 05-08-07 AI95-00397/07
!standard 8.3.1(1)
!standard 9.1(9.1)
!standard 9.4(11)
!standard 9.5.2(2)
!standard 9.5.2(10)
!standard 9.5.2(13)
!standard 10.1.1(8)
!class amendment 05-01-25
!status Amendment 200Y 05-03-14
!status ARG Approved 10-0-0 05-02-13
!status work item 05-01-25
!status received 05-01-25
!priority High
!difficulty Easy
!subject Conformance and overriding for entries and protected operations
!summary
(See proposal.)
!problem
6.3.1(24/1) talks about subtype conformance of an entry and a subprogram, but
an entry and a subprogram never have the same convention. Furthermore, it would
seem that we would want the overriding indicators to be usable for entries and
protected subprograms, even though they don't override anything (they implement
the parent subprogram).
Finally, if a prefixed view call is made to an operation of a tagged task or
protected type, the call could be ambiguous if there is both primitive
operations and protected operations or task entries that have the same
prefixed view profile.
!proposal
Defined the term prefixed view profile to reduce the verbiage about
"omitting the first parameter" and also to resolve the problem of convention
matching. Replicated the wording from 8.3 about overriding indicators, with the
simplification that entries and protected operations are not primitive
operations.
Also, fix the "implemented by" rules to be rechecked in the private part of
generic instances (certainly, we want these rules to be enforced everywhere).
Finally, add legality rules to prohibit primitive operations with matching
prefixed view profiles.
!wording
Replace the paragraph inserted by AI95-00345 after 6.3.1(24) by:
The prefixed view profile of a subprogram is the profile obtained by
omitting the first parameter of that subprogram. There is no prefixed view
profile for a parameterless subprogram. For the purposes of defining subtype
and mode conformance, the convention of a prefixed view profile is considered
to match that of either an entry or a protected operation.
AARM Note: The weird rule about conventions is pretty much required for
synchronized interfaces to make any sense. There will be wrappers all over the
place anyway. Of course, this doesn't imply that entries have the same
convention as protected operations.
Modify the first legality paragraph in the 8.3.1 clause added by AI-218-3 as
follows:
If a subprogram_declaration {other than a protected subprogram},
abstract_subprogram, ...
Add a Note to 8.3.1:
Rules for overriding_indicators of task and protected entries and of protected
subprograms are found in 9.5.2 and 9.4, respectively.
Replace the second paragraph inserted by AI95-00345 after 9.1(9.1/1) by:
For a task_type_declaration, if the first parameter of a primitive inherited
subprogram is of the task type or an access parameter designating the task type,
and there is an entry_declaration for a single entry with the same identifier
within the task_type_declaration, whose profile is type conformant with the
prefixed view profile of inherited subprogram, the inherited subprogram is
said to be implemented by the conforming task entry.
Add after the third paragraph inserted by AI95-00345 after 9.1(9.1/2):
The prefixed view profile of an explicitly declared
primitive subprogram of a tagged task type shall not be type
conformant with any entry of the task type, if the first
parameter of the subprogram is of the task type or is an
access parameter designating the task type.
Replace the seventh paragraph inserted by AI95-00345 after 9.1(9.1/1) (the second
bullet) by:
o the inherited subprogram is implemented by a single entry of the task type;
in which case its prefixed view profile shall be subtype conformant with that
of the task entry.
Replace the eighth paragraph inserted by AI95-00345 after 9.1(9.1/1) (the second
bullet) by:
If neither applies, the inherited subprogram shall be a null procedure. In
addition to the places where Legality Rules normally apply (see 12.3), these
rules also apply in the private part of an instance of a generic unit.
Replace the paragraph inserted by AI95-00345 after 9.4(11) by:
For a protected_type_declaration, if the first parameter of a primitive
inherited subprogram is of the protected type or an access parameter
designating the protected type, and there is a protected_operation_declaration
for a protected subprogram or single entry with the same identifier within the
protected_type_declaration, whose profile is type conformant with the prefixed
view profile of the inherited subprogram, the inherited subprogram is said
to be implemented by the conforming protected subprogram or entry.
Add after the third paragraph inserted by AI95-00345 after 9.4(11):
The prefixed view profile of an explicitly declared primitive subprogram of a
tagged protected type shall not be type conformant with any protected operation
of the protected type, if the first parameter of the subprogram is of the
protected type or is an access parameter designating the protected type.
Replace the sixth paragraph inserted by AI95-00345 after 9.4(11) (the second
bullet) by:
o the inherited subprogram is implemented by a protected subprogram or single
entry of the protected type, in which case its prefixed view profile shall be
subtype conformant with that of the protected subprogram or entry.
Replace the seventh paragraph inserted by AI95-00345 after 9.4(11) by:
If neither applies, the inherited subprogram shall be a null procedure. In
addition to the places where Legality Rules normally apply (see 12.3), these
rules also apply in the private part of an instance of a generic unit.
Add after the last paragraph inserted by AI95-00345 after 9.4(11):
If a protected subprogram declaration has an overriding_indicator, then:
o if the overriding_indicator is overriding, then the subprogram shall
implement an inherited subprogram, at the point of the declaration;
o if the overriding_indicator is not overriding, then the subprogram shall
not implement any inherited subprogram (at any point).
In addition to the places where Legality Rules normally apply (see 12.3), these
rules also apply in the private part of an instance of a generic unit.
Change 9.5.2(2) to read:
entry_declaration ::=
[overriding_indicator]
entry defining_identifier [(discrete_subtype_definition)] parameter_profile;
Add after 9.5.2(10):
An overriding_indicator is not allowed in an entry_declaration that includes
a discrete_subtype_definition.
Add after 9.5.2(13):
If an entry_declaration has an overriding_indicator, then:
o if the overriding_indicator is overriding, then the entry shall implement
an inherited subprogram, at the point of the declaration;
o if the overriding_indicator is not overriding, then the operation shall not
implement any inherited subprogram (at any point).
In addition to the places where Legality Rules normally apply (see 12.3), these
rules also apply in the private part of an instance of a generic unit.
AARM Note: An entry family never implements anything, so only not overriding
can be given on the declaration of a family.
Added after 10.1.1(8):
An overriding_indicator is not allowed in a subprogram_declaration,
generic_instantiation, or subprogram_renaming_declaration that declares a
library unit.
AARM Note: A library unit can never override anything.
!discussion
The wording for overriding indicators applied to entries and protected
subprograms was put this the definition of entries and protected subprograms,
respectively, because it depends on the technical term "implemented" which is
defined there. Putting it in 8.3 would have created a giant forward reference.
!example
Here is a simple readers and writers interface:
type RW is limited interface;
procedure Write (Obj : out RW; X : Integer) is abstract;
procedure Read (Obj : RW; X : out Integer) is abstract;
This interface may be implemented by a protected object. In order to allow
several readers to proceed in parallel, the Read subprogram is implemented by a
non-protected procedure that calls a protected function. The Write subprogram
is directly implemented by a protected procedure:
protected type Prot_RW is new RW with
overriding
procedure Write (X : Integer);
not overriding
function Read return Integer;
private
V : Integer;
end Prot_RW;
overriding
procedure Read (Obj : Prot_RW; X : out Integer);
(Credits: this example was shamelessly stolen from John Barnes' Rationale
document.)
!corrigendum 6.3.1(24)
Insert after the paragraph:
Two discrete_subtype_definitions are fully conformant if they are
both subtype_indications or are both ranges, the subtype_marks
(if any) denote the same subtype, and the corresponding simple_expressions
of the ranges (if any) fully conform.
the new paragraph:
The prefixed view profile of a subprogram is the profile obtained by
omitting the first parameter of that subprogram. There is no prefixed view
profile for a parameterless subprogram. For the purposes of defining subtype
and mode conformance, the convention of a prefixed view profile is considered
to match that of either an entry or a protected operation.
!corrigendum 8.3.1(1)
!comment This is a dummy just to cause a conflict.
@dinsa
@dinss
If a @fa<subprogram_declaration> {other than a protected subprogram},
@fa<abstract_subprogram>, ...
!corrigendum 9.1(9.1/1)
!comment This includes the wording change from AI-401 (deleting a paragraph).
@dinsa
For a task declaration without a @fa<task_definition>, a @fa<task_definition>
without @fa<task_item>s is assumed.
@dinss
For a @fa<task_type_declaration>, if the first parameter of a primitive inherited
subprogram is of the task type or an access parameter designating the task type,
and there is an @fa<entry_declaration> for a single entry with the same identifier
within the @fa<task_type_declaration>, whose profile is type conformant with the
prefixed view profile of inherited subprogram, the inherited subprogram is
said to be @i<implemented> by the conforming task entry.
@i<@s8<Legality Rules>>
A task declaration requires a completion, which shall be a @fa<task_body>, and
every @fa<task_body> shall be the completion of some task declaration.
Each @fa<interface_subtype_mark> of an @fa<interface_list> appearing within a
@fa<task_type_declaration> shall denote a limited interface type that
is not a protected interface.
The prefixed view profile of an explicitly declared
primitive subprogram of a tagged task type shall not be type
conformant with any entry of the task type, if the first
parameter of the subprogram is of the task type or is an
access parameter designating the task type.
For each primitive subprogram inherited by the type declared by a
@fa<task_type_declaration>, at most one of the following shall apply:
@xbullet<the inherited subprogram is overridden with a primitive
subprogram of the task type, in which case the overriding
subprogram shall be subtype conformant with the inherited
subprogram and not abstract; or>
@xbullet<the inherited subprogram is implemented by a single entry of the task type;
in which case its prefixed view profile shall be subtype conformant with that
of the task entry.>
If neither applies, the inherited subprogram shall be a null procedure. In
addition to the places where Legality Rules normally apply (see 12.3), these
rules also apply in the private part of an instance of a generic unit.
!corrigendum 9.4(11)
!comment This includes the wording change from AI-401 (deleting a paragraph).
@dinsa
A @fa<protected_definition> defines a protected type and its first subtype. The
list of @fa<protected_operation_declaration>s of a @fa<protected_definition>,
together with the @fa<known_discriminant_part>, if any, is called the visible
part of the protected unit. The optional list of
@fa<protected_element_declaration>s after the reserved word @b<private> is
called the private part of the protected unit.
@dinss
For a @fa<protected_type_declaration>, if the first parameter of a primitive
inherited subprogram is of the protected type or an access parameter
designating the protected type, and there is a @fa<protected_operation_declaration>
for a protected subprogram or single entry with the same identifier within the
@fa<protected_type_declaration>, whose profile is type conformant with the prefixed
view profile of the inherited subprogram, the inherited subprogram is said
to be @i<implemented> by the conforming protected subprogram or entry.
@i<@s8<Legality Rules>>
A protected declaration requires a completion, which shall be a
@fa<protected_body>, and every @fa<protected_body> shall be the completion of
some protected declaration.
Each @fa<interface_subtype_mark> of an @fa<interface_list> appearing within a
@fa<protected_type_declaration> shall denote a limited interface type that
is not a task interface.
The prefixed view profile of an explicitly declared primitive subprogram of a
tagged protected type shall not be type conformant with any protected operation
of the protected type, if the first parameter of the subprogram is of the
protected type or is an access parameter designating the protected type.
For each primitive subprogram inherited by the type declared by a
@fa<protected_type_declaration>, at most one of the following shall apply:
@xbullet<the inherited subprogram is overridden with a primitive
subprogram of the protected type, in which case the overriding
subprogram shall be subtype conformant with the inherited
subprogram and not abstract; or>
@xbullet<the inherited subprogram is implemented by a protected subprogram or single
entry of the protected type, in which case its prefixed view profile shall be
subtype conformant with that of the protected subprogram or entry.>
If neither applies, the inherited subprogram shall be a null procedure. In
addition to the places where Legality Rules normally apply (see 12.3), these
rules also apply in the private part of an instance of a generic unit.
If an inherited subprogram is implemented by a protected procedure or
an entry, then the first parameter of the inherited subprogram shall be
of mode @b<out> or @b<in out>, or an access-to-variable parameter.
If a protected subprogram declaration has an @fa<overriding_indicator>, then:
@xbullet<if the @fa<overriding_indicator> is @b<overriding>, then the subprogram shall
implement an inherited subprogram, at the point of the declaration;>
@xbullet<if the @fa<overriding_indicator> is @b<not overriding>, then the subprogram shall
not implement any inherited subprogram (at any point).>
In addition to the places where Legality Rules normally apply (see 12.3), these
rules also apply in the private part of an instance of a generic unit.
!corrigendum 9.5.2(2)
Replace the paragraph:
entry_declaration ::=
entry defining_identifier [(discrete_subtype_definition)] parameter_profile;
by:
entry_declaration ::=
[overriding_indicator]
entry defining_identifier [(discrete_subtype_definition)] parameter_profile;
!corrigendum 9.5.2(10)
Insert after the paragraph:
An entry_declaration is allowed only in a protected or task declaration.
the new paragraph:
An overriding_indicator is not allowed in an entry_declaration that
includes a discrete_subtype_definition.
!corrigendum 9.5.2(13)
Insert after the paragraph:
An entry_declaration in a task declaration shall not contain a specification for an access parameter (see 3.10).
the new paragraphs:
If an entry_declaration has an overriding_indicator, then:
- if the overriding_indicator is overriding, then the entry shall implement
an inherited subprogram, at the point of the declaration;
- if the overriding_indicator is not overriding, then the operation shall not
implement any inherited subprogram (at any point).
In addition to the places where Legality Rules normally apply (see 12.3), these
rules also apply in the private part of an instance of a generic unit.
!corrigendum 10.1.1(8)
Insert after the paragraph:
parent_unit_name ::= name
the new paragraph:
An overriding_indicator is not allowed in a subprogram_declaration,
generic_instantiation, or subprogram_renaming_declaration which
declares a library unit.
!ACATS test
ACATS B-Test(s) should be created to check that overriding indicators are
allowed and enforced here.
!appendix
****************************************************************
Questions? Ask the ACAA Technical Agent