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

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

--- ai12s/ai12-0389-1.txt	2020/09/11 22:23:10	1.2
+++ ai12s/ai12-0389-1.txt	2020/10/14 04:58:42	1.3
@@ -59,21 +59,58 @@
 Append after 13.12.1(6.3/3) (as part of the list of restriction identifiers)
 
     No_Unrecognized_Aspects
-      Any aspect_specification having an unrecognized *aspect_*identifier
-      shall be rejected[Redundant: (as opposed to being ignored)]. This 
+      There are no aspect_specifications having an unrecognized 
+      aspect_identifier. This restriction applies only to the current 
+      compilation or environment, not the entire partition.
+ 
+      AARM Ramification: When this restriction is in effect, unrecognized 
+      aspects cannot be ignored in the current compilation; they violate the 
+      restriction. This is true despite the Implementation Permission of 
+      13.1.1.
+
+    No_Unrecognized_Pragmas
+      There are no pragmas having an unrecognized pragma identifier. This 
       restriction applies only to the current compilation or environment, 
       not the entire partition.
 
-    No_Unrecognized_Pragmas
-      Any pragma having an unrecognized pragma identifier shall be
-      rejected[Redundant: (as opposed to being ignored)]. This restriction 
-      applies only to the current compilation or environment, not the entire
-      partition.
+      AARM Ramification: When this restriction is in effect, unrecognized 
+      pragmas cannot be ignored in the current compilation; they violate 
+      the restriction. This is true despite the rules of 2.8.
 
 !discussion
 
 (See problem.)
 
+!corrigendum 13.1.1(38/3)
+
+@dinsa
+Implementations may support implementation-defined aspects. The 
+@fa<aspect_specification> for an implementation-defined aspect may use an 
+implementation-defined syntax for the @fa<aspect_definition>, and may follow 
+implementation-defined legality and semantics rules. 
+@dinst
+An implementation may ignore the specification of an unrecognized
+aspect; if an implementation chooses to ignore such an aspect
+specification (as opposed to rejecting it), then it has no effect on
+the semantics of the program except for possibly (and this is not
+required) the rejection of syntax errors within the @fa<aspect_definition>.
+
+!corrigendum 13.12.1(6.3/3)
+
+@dinsa
+@xhang<@xterm<No_Use_Of_Pragma>
+Identifies a @fa<pragma> which is not to be used.>
+@dinss
+@xhang<@xterm<No_Unrecognized_Aspects>
+There are no @fa<aspect_specification>s having an unrecognized 
+@i<aspect_>@fa<identifier>. This restriction applies only to the current 
+compilation or environment, not the entire partition.>
+
+@xhang<@xterm<No_Unrecognized_Pragmas>
+There are no @fa<pragma>s having an unrecognized pragma @fa<identifier>. This 
+restriction applies only to the current compilation or environment, not the 
+entire partition.>
+
 !ASIS
 
 No ASIS effect.
@@ -410,5 +447,119 @@
 
 Here is an AI for this one, pretty much just writing up what has already 
 been discussed. [This is version /01 of this AI - Editor.]
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, October 2, 2020  9:52 PM
+
+In this AI, we define a restriction as follows:
+
+  No_Unrecognized_Aspects
+
+  Any aspect_specification having an unrecognized aspect_identifier shall be
+  rejected[ (as opposed to being ignored)]. This restriction applies only to
+  the current compilation or environment, not the entire partition.
+
+Bob has typically complained about the use of "reject" in normative wording. 
+Dunno if he napped through the review of this AI :-), but this is precisely 
+the sort of use that he has complained about in the past.
+
+Moreover, this is not the typical form for a restriction, which starts 
+something like "There are no ...". Probably it would be better to use 
+wording something like:
+
+  There are no aspect_specifications having an unrecognized aspect_identifier;
+  they are not ignored. This restriction applies only to
+  the current compilation or environment, not the entire partition.
+
+I'm dubious that the part about not ignoring buys anything (at least 
+normatively), since "no aspect_identifiers" doesn't depend on whether they're 
+ignored. So perhaps drop that and explain in an AARM note that this does not 
+allow ignoring aspects:
+
+  There are no aspect_specifications having an unrecognized aspect_identifier. 
+  This restriction applies only to the current compilation or environment, not
+  the entire partition.
+
+  Ramification: When this restriction is in effect, unrecognized 
+  aspect_identifiers cannot be ignored; the Implementation Permission of 
+  13.1.1 does not apply.
+
+I'd make a similar change to No_Unrecognized_Pragmas:
+
+  No_Unrecognized_Pragmas
+  There are no pragmas having an unrecognized pragma identifier. This 
+  restriction applies only to the current compilation or environment, not the 
+  entire partition.
+
+If no one objects, I can treat these rewordings as my editorial review of 
+this AI.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, October 3, 2020  6:37 AM
+
+> In this AI, we define a restriction as follows:
+> 
+>   No_Unrecognized_Aspects
+> 
+>   Any aspect_specification having an unrecognized aspect_identifier shall be
+>   rejected[ (as opposed to being ignored)]. This restriction applies only to
+>   the current compilation or environment, not the entire partition.
+> 
+> Bob has typically complained about the use of "reject" in normative wording.
+> Dunno if he napped through the review of this AI :-), ...
+
+Apparently.
+
+> Moreover, this is not the typical form for a restriction, which starts 
+> something like "There are no ...". Probably it would be better to use 
+> wording something like:
+> 
+>   There are no aspect_specifications having an unrecognized aspect_identifier;
+>   they are not ignored. This restriction applies only to
+>   the current compilation or environment, not the entire partition.
+
+OK.
+
+> I'm dubious that the part about not ignoring buys anything (at least 
+> normatively), ...
+
+Yeah, that's why it's in square brackets in the original you quoted above.
+
+> ...since "no aspect_identifiers" doesn't depend on whether they're 
+> ignored. So perhaps drop that and explain in an AARM note that this 
+> does not allow ignoring aspects:
+> 
+>   There are no aspect_specifications having an unrecognized aspect_identifier.
+>   This restriction applies only to the current compilation or environment, not
+>   the entire partition.
+> 
+>   Ramification: When this restriction is in effect, unrecognized 
+>   aspect_identifiers cannot be ignored; the Implementation Permission of 
+>   13.1.1 does not apply.
+
+I've no opinion whether the non-normative-but-perhaps-informative
+part should be moved to the AARM.
+
+> I'd make a similar change to No_Unrecognized_Pragmas:
+> 
+>   No_Unrecognized_Pragmas
+>   There are no pragmas having an unrecognized pragma identifier. This restriction
+>   applies only to the current compilation or environment, not the entire partition.
+> 
+> If no one objects, I can treat these rewordings as my editorial review 
+> of this AI.
+
+OK!
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, October 3, 2020  8:48 AM
+
+Works for me.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent