!standard 9.1(3)                                    05-06-05  AI95-00399/03
!standard 9.4(3)
!class amendment 05-01-25
!status Amendment 200Y 05-03-08
!status WG9 Approved 06-06-09
!status ARG Approved 8-0-2  05-02-12
!status work item 05-01-25
!status received 05-01-25
!priority High
!difficulty Easy
!subject Single task and protected objects implementing interfaces

!summary

(See proposal.)

!problem

The current syntax only allows a task or protected *type* to implement (one or
several) interfaces. This is an unnecessary restriction: it makes perfect sense
for a single task or protected object declaration to implement an interface.
There is no reason to make single task or protected objects less functional
than types. This is especially important if users want to take advantage of
interfaces in existing code.

!proposal

(See wording.)

!wording

Change 9.1(3) to read:

	single_task_declaration ::=
	   task defining_identifier [is
             [new interface_list with]
             task_definition];

Change "task_type_declaration" in the first, fourth, and fifth paragraph
added by AI-345 after 9.1(9.1) to "task declaration".

Change 9.4(3) to read:

	single_protected_declaration ::=
	   protected defining_identifier is
	     [new interface_list with]
	     protected_definition;

Change "protected_type_declaration" in the first, fourth, and fifth paragraphs
added by AI-345 after 9.4(11) to "protected declaration".

!discussion

One might naively think that, because the type of a single task or protected
object is anonymous, the interface inheritance facility is not too useful.
After all, there is no way to name the derived type. So this means that a
subprogram inherited from some interface cannot be *overridden*. However,
because the task or protected object is an implicit parameter of the entries
and protected subprograms it declares, such an inherited subprogram can be
*implemented*, as shown by the example below:

	type Map is protected interface;
	procedure Put (M: Map; K : Key; V : Value) is abstract;

	protected My_Protected_Map is
	   new Map with

	   procedure Put (K : Key; V : Value);

	end My_Protected_Map;

!example

(See discussion.)

!corrigendum 9.1(3)

@drepl
@xcode<@fa<single_task_declaration ::=
   >@ft<@b<task>>@fa< defining_identifier [>@ft<@b<is>>@fa< task_definition];>>
@dby
@xcode<@fa<single_task_declaration ::=
   >@ft<@b<task>>@fa< defining_identifier [>@ft<@b<is>>@fa<
     [>@ft<@b<new>>@fa< interface_list >@ft<@b<with>>@fa<]
     task_definition];>>

!corrigendum 9.1(9.1/1)
!comment This is a dummy to force a conflict.

@dinsa
For a task declaration without a @fa<task_definition>, a @fa<task_definition>
without @fa<task_item>s is assumed.
@dinss
Dummy, dummy, dummy.

!corrigendum 9.4(3)

@drepl
@xcode<@fa<single_protected_declaration ::=
   >@ft<@b<protected>>@fa< defining_identifier >@ft<@b<is>>@fa< protected_definition;>>
@dby
@xcode<@fa<single_protected_declaration ::=
   >@ft<@b<protected>>@fa< defining_identifier >@ft<@b<is>>@fa<
     [>@ft<@b<new>>@fa< interface_list >@ft<@b<with>>@fa<]
     protected_definition;>>

!corrigendum 9.4(11)
!comment This is a dummy to force a conflict.

@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
Dummy, dummy, dummy.


!ACATS test

ACATS C-Test(s) should be created to insure this works.


!appendix

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