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

Differences between 1.7 and version 1.8
Log of other versions for file ai12s/ai12-0342-1.txt

--- ai12s/ai12-0342-1.txt	2020/01/17 03:50:44	1.7
+++ ai12s/ai12-0342-1.txt	2020/01/24 05:35:21	1.8
@@ -103,7 +103,7 @@
    subprogram denoted by the corresponding aspect of T: the
    Integer_Literal aspect for an integer literal, the Real_Literal aspect
    for a real literal, and the String_Literal aspect for a string_literal.
-   The actual parameter of this notional call is a string literal
+   The actual parameter of this notional call is a string_literal
    having the textual representation of the original (numeric or string) 
    literal.
 
@@ -120,15 +120,22 @@
    by the usual rules for the bounds of a string literal.
    End AARM Discussion.
 
-   Such a literal is said to be a "user-defined literal".
+   Such a literal is said to be a *user-defined literal*.
 
-Append after 4.2.1(6/5) (at the end of the Legality Rules section)
+Insert the following between the second and third sentences of 4.2.1(6/5) (in 
+the Legality Rules section), making three separate paragraphs:
 
-   If a nonabstract tagged type other than a null extension inherits any 
-   user-defined literal aspect, then each inherited aspect shall be 
-   directly specified for the type.
+   For a nonabstract type, the function directly specified for a user-defined 
+   literal aspect shall not be abstract.
 
+   For a tagged type with a partial view, a user-defined literal aspect shall 
+   not be directly specified on the full type.
 
+   If a nonabstract tagged type inherits any user-defined literal aspect, then 
+   each inherited aspect shall be directly specified as a nonabstract function 
+   for the type unless the inherited aspect denotes a nonabstract function and 
+   the type is a null extension.
+
 Delete 4.2.1(7-8/5).
    [This is the entire Dynamic Semantics section (it is now redundant).]
 
@@ -163,8 +170,12 @@
      if and only if the corresponding literal in the other is also a
      user-defined literal. Furthermore, if neither are user-defined literals
      then they shall have the same values Redundant[, but they may have
-     differing textual representations]; if both are user-defined literals then
-     they shall have the same textual representation.
+     differing textual representations]; if both are user-defined literals 
+     then they shall have the same textual representation.
+
+  AARM Ramification: This rule applies to character_literals, so even though 
+  other rules would allow a rename of a character literal to conform to the 
+  literal, this rule prevents that.
 
 !discussion
 
@@ -181,6 +192,15 @@
 We define a name for these attributes collectively so that we can easily
 name them in various rules.
 
+We do have to require that the operations are not abstract for a 
+nonabstract type. For untagged types, this is merely a convinience: any call
+on such a function is illegal, so the corresponding literal would be illegal,
+too. Detecting the error early seems better, however. In the case of a tagged
+type, we need to enforce rule on the type declaration so that it is not 
+possible to dispatch to an abstract literal. Similarly, we need rules to 
+ensure that any inherited functions are overridden unless the type is a null
+extension (for which the language will construct the needed function).
+
 ----
 
 Because these are aspects, we don't get reemergence with
@@ -209,6 +229,114 @@
 
 the variable I.X is initialized with the value T2_Op, not T1_Op.]
 
+----
+
+The rule that does not allow hiding these aspects for tagged types is 
+necessary to avoid a situation where a user-defined literal aspect needs 
+to be overridden but that aspect is not visible. For instance:
+
+    package P is
+       type T is tagged private;
+       function Val (S : Wide_Wide_String) return T;
+    private
+       type T is tagged record ...
+           with String_Literal => Val;
+    end P;
+
+    with P;
+    package P2 is
+       type T2 is new P.T with record ...;
+       overriding
+       function Val (S : Wide_Wide_String) return T2;
+    end P2;
+
+Type T2 needs to override the String_Literal aspect, yet that aspect is not
+visible. (The overriding is necessary in case a dispatching literal is used
+with T'Class within the scope of the full type of T. We have to have a function
+to execute for T2 in that case.)
+
+Note that this is required for nonoverridable aspects like Variable_Indexing.
+We don't make these aspects nonoverriddable since that does not work well for
+untagged types, and therefore we need our own rule to ensure this.
+
+----
+
+The new AARM Ramification for 6.3.1(22) is just noting that both
+6.3.1(21/4) and 6.3.1(22/5) apply to character literals. In particular:
+
+    type Mixed is ('A', 'B', Sea);
+    function Ocean return Mixed renames Sea;
+    function Bad return Mixed renames 'B';
+
+    procedure P1 (A : Mixed := 'B');
+    procedure P2 (A : Mixed := Sea);
+
+    procedure P1 (A : Mixed := Bad); -- Illegal.
+    procedure P2 (A : Mixed := Ocean); -- OK.
+
+Even though 'B' and Bad denote the same declaration (thus satisfying
+6.3.1(21/4)), they are not both literals, so 6.3.1(22/5) is not satisfied.
+Contrast to P2, where Sea and Ocean conform.
+
+Argubly, it is a mistake to include character literals in 6.3.1(22/5) - as they
+denote declarations, not values, but it is insufficiently broken to change. (The 
+situation above is likely very rare, and primary goal of the conformance rules
+is to allow exact matches with just a bit of wiggle room.)
+
+!corrigendum 3.9.2(1/2)
+
+@drepl
+The primitive subprograms of a tagged type, the subprograms declared by
+@fa<formal_abstract_subprogram_declaration>s, and the stream attributes of a
+specific tagged type that are available (see 13.13.2) at the end of the
+declaration list where the type is declared are called @i<dispatching
+operations>. A dispatching operation can be called using a statically
+determined @i<controlling> tag, in which case the body to be executed is
+determined at compile time. Alternatively, the controlling tag can be
+dynamically determined, in which case the call @i<dispatches> to a body that is
+determined at run time; such a call is termed a @i<dispatching call>. As
+explained below, the properties of the operands and the context of a particular
+call on a dispatching operation determine how the controlling tag is
+determined, and hence whether or not the call is a dispatching call. Run-time
+polymorphism is achieved when a dispatching operation is called by a
+dispatching call.
+@dby
+The primitive subprograms of a tagged type, the subprograms declared by
+@fa<formal_abstract_subprogram_declaration>s, the subprograms identified by
+the user-defined literal aspects of a specific tagged type (see 4.2.1),
+and the stream attributes of a
+specific tagged type that are available (see 13.13.2) at the end of the
+declaration list where the type is declared are called @i<dispatching
+operations>. A dispatching operation can be called using a statically
+determined @i<controlling> tag, in which case the body to be executed is
+determined at compile time. Alternatively, the controlling tag can be
+dynamically determined, in which case the call @i<dispatches> to a body that is
+determined at run time; such a call is termed a @i<dispatching call>. As
+explained below, the properties of the operands and the context of a particular
+call on a dispatching operation determine how the controlling tag is
+determined, and hence whether or not the call is a dispatching call. Run-time
+polymorphism is achieved when a dispatching operation is called by a
+dispatching call.
+
+!corrigendum 4.2.1(0)
+
+@dinsc
+
+** Force a conflict; the actual changes are in the conflict file. **
+
+!corrigendum 6.3.1(22)
+
+@drepl
+Each @fa<primary> that is a literal in one has the same value as the 
+corresponding literal in the other. 
+@dby
+each @fa<primary> that is a literal in one is a user-defined literal
+if and only if the corresponding literal in the other is also a
+user-defined literal. Furthermore, if neither are user-defined literals
+then they shall have the same values, but they may have
+differing textual representations; if both are user-defined literals then
+they shall have the same textual representation.
+
 !ASIS
 
 No change here; the aspects already exist.
@@ -870,11 +998,145 @@
 
 To keep that wording from being unwieldy, we need to name these aspects. After
 consulting with Tucker Taft and Steve Baird, "user-defined literal aspects"
-was chosen. We then used this name rather than other vague descriptions or
+was chosen. We then used this term rather than other vague descriptions or
 lists of attributes - this makes the wording of 4.2.1 much clearer (and more
 resistant to future problems should we decide to add Character_Literal or
 Null_Literal in the future).
 
 We considered this part of the editorial review of this AI.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 23, 2020  11:40 PM
+
+I made the mistake of thinking about AI12-0342-1 rather than mechanically 
+adding the wording to the draft RM, and thus I found a number of issues that 
+needed fixing in the AI. All of these have been reviewed by Steve and Tucker, 
+and they agree with me that none of these rise to the level of something that 
+requires reopening the AI.
+
+So, if anyone of you want to discuss these changes at a meeting, please speak 
+up and we'll put the AI back on the agenda for the next meeting. Otherwise, we
+will process this as my editorial review of the AI and we won't spend limited 
+meeting time on it again.
+
+I've posted the updated AI on the website (in the version control only) if you
+want to look at the detailed changes and/or diffs.
+
+                             Randy Brukardt, ARG Editor.
+
+
+[1] The proposed wording had "each inherited aspect shall be overridden". But
+"shall be overridden" is not defined for aspects, we should have said
+"shall be directly specified".
+
+[2] We want these aspects to be dispatching for tagged types, so that they are
+available for classwide subtypes. That requires specific wording in 3.9.2(1).
+(These are modeled after stream-oriented attributes, and *those* have specific
+wording in 3.9.2(1)).
+
+[3] To keep that wording from being unwieldy, we need to name these aspects. After
+consulting with Tucker Taft and Steve Baird, "user-defined literal aspects"
+was chosen. We then used this term in all of the wording of 4.2.1 rather than other 
+vague descriptions or lists of attributes - this makes the wording of 4.2.1 much 
+clearer (and more resistant to future problems should we decide to add Character_Literal or
+Null_Literal in the future). This does change a number of paragraphs and AARM notes
+not otherwise changed.
+
+[4] The added Legality Rule needs to be enforced in all of a generic specification
+and rechecked in an instance in case the type extension has a parent type that
+is a generic formal type. In that case, we don't necessarily know whether 
+something is inherited until the instance is processed. Moreover, allowing
+such an extension would be to have objects created without all of the 
+components of the extension, which clearly cannot be allowed. Note that
+deriving a type from a tagged formal type is not allowed in a generic body
+(specifically because inheritance rules such as abstract operation rules
+cannot be enforced).
+
+This was handled with the editorial changes of moving the generic boilerplate
+sentence from 4.2.1(6/5) to its own paragraph at the end of the Legality Rules
+section and inserting the new rule in between.
+
+[5] We want to prevent a user-defined literal aspect being directly specified
+as an abstract function for a nonabstract type. (We want to allow it on abstract 
+types so that interfaces and the like can define literals - if the literal is an
+important part of the abstraction, it would be bad to not be able to define it.)
+
+For untagged types, this is just a convenience: any literal would be illegal by
+the static semantics equivalence. But there's little point in allowing a 
+declaration for which any use would be illegal. For tagged types, however, it
+would be possible to dispatch to the literal function from some ancestor, and we 
+surely cannot allow executing an abstract function.
+
+To handle this, we add the following rule:
+
+   For a nonabstract type, the function directly specified for a user-defined 
+   literal aspect shall not be abstract.
+
+[6] We have a similar problem when inheriting abstract functions (if we allow that
+one could call an abstract function via a dispatching call). Thus, we change the
+originally proposed Legality Rule to:
+
+   If a nonabstract tagged type inherits any user-defined literal aspect, then 
+   each inherited aspect shall be directly specified as a nonabstract function 
+   for the type unless the inherited aspect denotes a nonabstract function and 
+   the type is a null extension.
+
+[7] Enforcing the above rule could be a problem if there are hidden specifications
+of a user-defined literal aspect. For example:
+
+    package P is
+       type T is tagged private;
+       function Val (S : Wide_Wide_String) return T;
+    private
+       type T is tagged record ...
+           with String_Literal => Val;
+    end P;
+
+    with P;
+    package P2 is
+       type T2 is new P.T with record ...;
+       overriding
+       function Val (S : Wide_Wide_String) return T2;
+    end P2;
+
+Type T2 needs to override the String_Literal aspect, yet that aspect is not
+visible. (The overriding is necessary in case a dispatching literal is used
+with T'Class within the scope of the full type of T. We have to have a function
+to execute for T2 in that case.)
+
+Hidden literals seem contrary to the purpose of these aspects (which is to define
+literals for private types). Moreover, we have a similar rule for nonoverridable
+aspects like Variable_Indexing and Implicit_Dereference.
+
+[8] The new 6.3.1(22) (and the old one, as well) apply to character_literals. But
+6.3.1(21/4) also applies to character_literals. This looks like a mistake, but it
+isn't worth fixing this as conformance does not need to be very smart. As such, I
+added an AARM note after 6.3.1(22):
+
+  AARM Ramification: This rule applies to character_literals, so even though 
+  other rules would allow a rename of a character literal to conform to the 
+  literal, this rule prevents that.
+
+This note is talking about a case like:
+
+    type Mixed is ('A', 'B', Sea);
+    function Ocean return Mixed renames Sea;
+    function Bad return Mixed renames 'B';
+
+    procedure P1 (A : Mixed := 'B');
+    procedure P2 (A : Mixed := Sea);
+
+    procedure P1 (A : Mixed := Bad);   -- Illegal.
+    procedure P2 (A : Mixed := Ocean); -- OK.
+
+Even though 'B' and Bad denote the same declaration (thus satisfying
+6.3.1(21/4)), they are not both literals, so 6.3.1(22/5) is not satisfied.
+Contrast that to P2, where Sea and Ocean conform.
+
+[9] I put quite a bit of the above into the !discussion of the AI.
+
+
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent