Version 1.3 of ais/ai-00397.txt

!standard 6.3.1(24) 05-03-15 AI95-00397/02
!standard 9.1(9.1)
!standard 9.4(11)
!standard 9.5.2(2)
!standard 9.5.2(10)
!standard 9.5.2(13)
!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

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).

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.

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.

Replace the third 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.

Replace the eighth 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 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.

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.

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

o if the overriding_indicator is not overriding, then the subprogram shall

Change 9.5.2(2) to read:

Add after 9.5.2(10):

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

o if the overriding_indicator is not overriding, then the operation shall not

AARM Note: An entry family never implements anything, so only not overriding can be given on the declaration of a family.

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.

Here is a simple readers and writers interface:

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;

(Credits: this example was shamelessly stolen from John Barnes' Rationale document.)

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.

@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.

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.

@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.

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 is a null procedure.

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.