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

--- ai05s/ai05-0266-1.txt	2011/12/20 07:56:41	1.2
+++ ai05s/ai05-0266-1.txt	2012/01/05 06:19:33	1.3
@@ -153,8 +153,6 @@
 So we will not consider any such effects here.
 
 !corrigendum 1.1.4(14.2/2)
-!AI-0227-1
-!AI-0266-1
 
 @drepl
 When this International Standard mentions the conversion of some character or
@@ -196,22 +194,22 @@
 @drepl
 The character repertoire for the text of an Ada program consists of the entire coding space
 described by the ISO/IEC 10646:2003 Universal Multiple-Octet Coded Character Set. This
-coding space is organized in @i<planes>, each plane comprising 65536 characters. 
+coding space is organized in @i<planes>, each plane comprising 65536 characters.
 @dby
 The character repertoire for the text of an Ada program consists of the entire coding space
 described by the ISO/IEC 10646:2011 Universal Multiple-Octet Coded Character Set. This
-coding space is organized in @i<planes>, each plane comprising 65536 characters. 
+coding space is organized in @i<planes>, each plane comprising 65536 characters.
 
 !corrigendum 2.1(3.1/2)
 
 @drepl
 A @fa<character> is defined by this International Standard for each cell in the coding
 space described by ISO/IEC 10646:2011, regardless of whether or not ISO/IEC
-10646:2011 allocates a character to that cell. 
+10646:2011 allocates a character to that cell.
 @dby
 A @fa<character> is defined by this International Standard for each cell in the coding
 space described by ISO/IEC 10646:2011, regardless of whether or not ISO/IEC
-10646:2011 allocates a character to that cell. 
+10646:2011 allocates a character to that cell.
 
 !corrigendum 2.1(4/2)
 
@@ -219,12 +217,12 @@
 The coded representation for characters is implementation defined
 (it need not be a representation defined within ISO/IEC 10646:2003).
 A character whose relative code position in its plane is 16#FFFE# or 16#FFFF#
-is not allowed anywhere in the text of a program. 
+is not allowed anywhere in the text of a program.
 @dby
 The coded representation for characters is implementation defined
 (it need not be a representation defined within ISO/IEC 10646:2011).
 A character whose relative code point in its plane is 16#FFFE# or 16#FFFF#
-is not allowed anywhere in the text of a program. 
+is not allowed anywhere in the text of a program.
 The only characters allowed outside of comments are those in categories
 @fa<other_format>, @fa<format_effector>, and @fa<graphic_character>.
 
@@ -1472,3 +1470,132 @@
 
 ****************************************************************
 
+From: Randy Brukardt
+Sent: Monday, December 19, 2011  10:13 PM
+
+I went to the ISO web site to check the exact spelling of the C standard name
+(to make sure that we have it right in 1.2), and what did I find? A brand new C
+standard!
+
+    ISO/IEC 9899:2011  Information Technology - Programming Languages - C, published 2011-12-08
+
+Based on our discussion in Denver (and our decision to use the 2011 C++
+standard), I'll use this in 1.2 instead of the old one.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, December 19, 2011  10:07 PM
+
+I just happened to notice that the new package Ada.Wide_Characters.Handling is
+not classified at all. That seems to me to be an oversight, as these are all
+pure functions. The Ada.Characters.Handling package that this is modeled on is
+classified as Pure.
+
+I will add this to AI05-0266-1 (which is modifying this package anyway), barring
+any objections. (We've already voted that AI, so any objection will require
+putting it in a different [not necessarily separate] AI so that it can be
+voted.)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, December 20, 2011   6:18 AM
+
+In GNAT, the pragmas for Ada.Characters.Handling are:
+
+>    pragma Preelaborate;
+>    pragma Pure_05;
+>    --  In accordance with Ada 2005 AI-362
+
+But indeed Ada.[Wide_]Wide_Characters.Handling have no pragmas
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, December 20, 2011   1:19 PM
+
+Is there any reason that they can't have pragma Pure, or was this just an
+oversight as I think it was??
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, December 20, 2011   5:54 PM
+
+I think an oversight, when did Ada.Wide_Characters.Handling enter the language?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, December 20, 2011   6:25 PM
+
+It came from AI05-0185-1, it was originally (formally) proposed in November
+2009. I think it was talked about some before that, but we didn't have a
+proposal. No version of the AI ever had any categorization pragmas, so I think
+it was just missed.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, December 20, 2011   6:39 PM
+
+I have some vague memory that Wide_Chars.<something-or-other> was deliberately
+impure, whereas the Chars. version was pure, because it was thought that the
+Wide_ version needed some pointers or heap allocation or something.
+
+But I studied that AI, and I agree with Randy and Robert:
+it was just an oversight to leave out Pure in this case.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, December 20, 2011   7:33 PM
+
+OK, so it should be Pure, no question about it, I will edit the GNAT packages
+appropriately
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, December 21, 2011  9:38 PM
+
+...
+> I have some vague memory that Wide_Chars.<something-or-other>
+> was deliberately impure, whereas the Chars. version was pure,
+> because it was thought that the Wide_ version needed some
+> pointers or heap allocation or something.
+
+You're thinking of Ada.Strings.Maps and Ada.Strings.Wide_Maps. The thinking was
+that Character_Set should be implemented as a simple bitmap, but requiring the
+use of 65536 bit set objects was over the top for Wide_Character_Set. (And
+imagine the fun for Wide_Wide_Character_Set!) So an implementation using
+(internal) access types was permitted, and that cannot be Pure, so Wide_Maps is
+preelaborated.
+
+But Ada.Wide_Characters.Handling doesn't use anything from Ada.Strings, so this
+reason doesn't apply here. (And even if it did, this should be preelaborated,
+and that wasn't done either.)
+
+> But I studied that AI, and I agree with Randy and Robert:
+> it was just an oversight to leave out Pure in this case.
+
+Thanks.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, December 23, 2011  10:22 AM
+
+> I just happened to notice that the new package 
+> Ada.Wide_Characters.Handling is not classified at all. That seems to 
+> me to be an oversight, as these are all pure functions. The 
+> Ada.Characters.Handling package that this is modeled on is classified as Pure.
+
+Interestingly, this was not quite trivial to implement in GNAT. The package bodies
+depended on some other bodies which have what are in fact completely static array
+constants, but because of over energetic rules are not technically static. Luckily
+we compile the run-time in a special mode where such categorization errors are warnings
+that can be suppressed :-)
+
+****************************************************************