CVS difference for ai12s/ai12-0041-1.txt

Differences between 1.2 and version 1.3
Log of other versions for file ai12s/ai12-0041-1.txt

--- ai12s/ai12-0041-1.txt	2013/12/19 03:44:11	1.2
+++ ai12s/ai12-0041-1.txt	2014/11/18 06:52:29	1.3
@@ -1,5 +1,8 @@
-!standard 7.3.2(3/3)                                12-11-29    AI12-0041-1/01
-!class Amendment 12-11-29
+!standard 7.3.2(1/3)                                14-11-17    AI12-0041-1/02
+!standard 7.3.2(3/3)
+!class binding interpretation 14-10-19
+!status Corrigendum 2015 14-11-17
+!status ARG Approved 6-0-2  14-10-19
 !status promising 11-0-0  13-11-16
 !status work item 12-11-29
 !status received 12-09-27
@@ -10,7 +13,7 @@
 
 Allow specifying Type_Invariant'Class for interface types.
 
-!problem
+!question
 
 Type_Invariant is used on a private type to define constraints on the
 implementation. As such, they are particularly useful when derivation is used as
@@ -25,25 +28,34 @@
 one to express the relation between primitives and / or the type and its
 environment.
 
-!proposal
+!recommendation
 
 Allow Type_Invariant'Class on interfaces. When a type implements one or several
-interfaces, its inherited type invariant would then be the combination of all
+interfaces, its inherited type invariant would then be the conjunction of all
 ancestor Type_Invariant'Class.
 
 !wording
 
 7.3.2 Type Invariants
 
+Modify 7.3.2(1/3):
+
+For a private type{,}[ or] private extension,{ or interface,} the following
+language-defined aspects may be specified with an aspect_specification
+(see 13.1.1):
+
 Modify 7.3.2(3/3):
 
 Type_Invariant'Class
 This aspect shall be specified by an expression, called an invariant expression.
-Type_Invariant'Class may be specified on a private_type_declaration, a
+Type_Invariant'Class may be specified on a private_type_declaration{,}[ or] a
 private_extension_declaration{, or an interface_type_declaration}.
 
 !discussion
 
+The existing Dynamic Semantics that describes invariant checks works perfectly
+for interfaces; it does not need any changes.
+
 Note that an abstract null record is very similar to an interface. We could
 allow them with no other changes. We didn't do this as it doesn't seem to add
 much to the language, and allowing components would cause problems (see next
@@ -60,18 +72,41 @@
 
 Note that the problem of AI12-0042-1 appears to be related to this AI,
 but it isn't really related as it can happen whether or not interfaces
-allow invariants. Whatever solution is adopted for that AI will work
-for interfaces.
+allow invariants. The solution adopted for that AI will work for interfaces.
 
 !example
 
 -- This window should always display exactly 100 pixels
 
 type Window is interface
-   with Type_Invariant'Class => This.Get_Width * This.Get_Height = 100;
+   with Type_Invariant'Class => Window.Get_Width * Window.Get_Height = 100;
 
 function Get_Width (This : Window) return Integer is abstract;
 function Get_Height (This : Window) return Integer is abstract;
+
+!corrigendum 7.3.2(1/3)
+
+@drepl
+For a private type or private extension, the following language-defined aspects
+may be specified with an @fa<aspect_specification> (see 13.1.1):
+@dby
+For a private type, private extension, or interface, the following
+language-defined aspects may be specified with an @fa<aspect_specification>
+(see 13.1.1):
+
+!corrigendum 7.3.2(3/3)
+
+@drepl
+@xhang<@xterm<Type_Invariant'Class>
+This aspect shall be specified by an @fa<expression>, called an
+@i<invariant expression>. Type_Invariant'Class may be specified on a
+@fa<private_type_declaration> or a @fa<private_extension_declaration>.>
+@dby
+@xhang<@xterm<Type_Invariant'Class>
+This aspect shall be specified by an @fa<expression>, called an
+@i<invariant expression>. Type_Invariant'Class may be specified on a
+@fa<private_type_declaration>, a @fa<private_extension_declaration>, or
+an @fa<interface_type_declaration>.>
 
 !ACATS test
 

Questions? Ask the ACAA Technical Agent