CVS difference for 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