CVS difference for ai05s/ai05-0241-1.txt

--- ai05s/ai05-0241-1.txt	2011/04/19 03:27:12	1.6
+++ ai05s/ai05-0241-1.txt	2011/04/22 02:50:58	1.7
@@ -448,9 +448,171 @@
 
 There is confusion between "No_(Aspect_Specification)" and "No_Aspect_(Specification)".
 
-Tucker suggests naming these restrictions  No_Implementation_Aspect_Specifications and 
+Tucker suggests naming these restrictions  No_Implementation_Aspect_Specifications and
 No_Specification_of_Aspect. That seems better.
 
 Approve AI with changes: 7-0-1.
+
+****************************************************************
+
+From: John Barnes
+Sent: Tuesday, April 19, 2011  5:16 AM
+
+> Actually, it is clear from the minutes of the February meeting that we
+> wanted No_Implementation_Aspect_Specifications, because this
+> restriction is only talking about the use of an aspect_specification
+> to specify an implementation-defined aspect, as opposed to any use of
+> an implementation-defined aspect (including pragmas and
+> attribute_definition_clauses, which have their own, separate,
+> restrictions).
+> That means that AI05-0246-1 is also (slightly) wrong, but easily fixed.
+
+I see the logic.  Aspects can be set by pragmas. Truth before beauty. But is
+that the way users will see it? And it makes the rat ugly.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, April 19, 2011  7:36 AM
+
+I agree with John, horrible name, I think I will implement both in GNAT, since
+the shorter name seems so much more convenient and reasonable. It is a language
+laywer thing to worry about this (sort of like sticking to the notion that its a
+package declaration rather than a spec, or that generic packages are not
+packages, or that type declarations introduce subtypes :-))
+
+No_Implementation_Aspects is much clearer and there is no chance of confusion
+IMO.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, April 19, 2011  7:51 AM
+
+Somehow, to have an implementation-defined restriction for controlling use of
+implementation-defined aspect specifications seems a bit counter-productive. ;-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, April 19, 2011  7:53 AM
+
+Hmmm, grumble grumble, I suppose you are right. I just hate this hypercorrectism
+with terminology, NO user will think if aspects in the way the manual thinks of
+them.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, April 19, 2011  7:55 AM
+
+> Somehow, to have an implementation-defined restriction for controlling
+> use of implementation-defined aspect specifications seems a bit
+> counter-productive. ;-)
+
+Hey, how about a profile that is all of these no-implementation-nonsense
+restrictions combined together, at this stage we have a few, and it would make
+sense to have a profile
+
+   Profile (No_Implementation_Extensions);
+
+that includes all of them
+
+trivial to implement, and I suspect that's what most people will want rather
+than a delicately chosen subset.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, April 19, 2011  8:22 AM
+
+Actually, you made this suggestion before, we liked the idea, and it is already
+part of AI-241. So you were way ahead of yourself... ;-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, April 19, 2011  8:26 AM
+
+chuckle chuckle, in practice I suspect that most people will use this profile
+rather than the individual ones.
+
+I havent read through 241 yet, was waiting for it to settle down :-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, April 19, 2011  3:38 PM
+
+Actually, the profile is in AI05-0246-1. But we definitely intend to include it
+in Ada 2012.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, April 19, 2011  9:14 AM
+
+Have we worried about implementation defined check names, and implementation
+defined policy names?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, April 19, 2011  9:30 AM
+
+No, though one way to do that might be to include them with
+implementation-defined pragmas.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, April 19, 2011  9:35 AM
+
+I think we should, obviously it's in the spirit of saying I only want officially
+defined pragmas. That should also kill special policies for dispatching etc.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, April 19, 2011  9:43 AM
+
+Or more generally, if you apply a restriction disallowing implementation-defined
+<blah>, that also should preclude using a language-defined <blah> with an
+implementation-defined identifier or syntax of some sort.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, April 19, 2011  9:48 AM
+
+Right, I think the proper definition is something like
+
+pragma Restriction (No_Implementation_Pragmas);
+
+If this restriction is in force, then the only allowed pragmas are those defined
+in the RM, and the only allowed syntax for these pragmas is that given in the
+RM.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, April 21, 2011  9:51 PM
+
+Actually, you guys need to read the Ada 2005 RM (13.12.1(3/2)):
+
+No_Implementation_Pragmas
+
+There are no implementation-defined pragmas or pragma arguments. This
+restriction applies only to the current compilation or environment, not the
+entire partition.
+
+Apparently, this is such a good idea that we had it 10 years ago. :-) This has
+always been the wording of this restriction, dating back to when the wording was
+created in June 2001. (On-line version control allows one to find out useless
+facts. :-)
+
+It is good that this already has this definition, because otherwise the rule you
+were talking about would have been incompatible with Ada 2005, which would be
+been annoying.
 
 ****************************************************************