AI22-0133-1

!standard 1.2(8/5)                                    25-08-15  AI22-0133-1/04

!standard 1.2.1(8/5)

!standard 2.1(1/5)

!standard 2.1(3.1/5)

!standard 2.1(4/5)

!standard 2.1(4.1/5)

!standard 2.1(15/5)

!standard 2.3(4.1/5)

!standard 3.5.2(2/6)

!standard 3.5.2(3/6)

!standard 3.5.2(4/6)

!standard A.1(36.1/5)

!standard A.1(36.2/5)

!standard A.3.2(32.6/5)

!standard A.3.2(60/3)

!standard A.3.5(33.2/5)

!standard A.3.5(51.2/5)

!standard A.3.5(61.2/5)

!standard A.3.5(63/5)

!standard A.4.6(8/5)

!class Binding Interpretation 25-05-13

!status Amendment 1-2022  25-05-30

!status WG9 Approved 25-10-08

!status ARG Approved  14-0-0  25-05-28

!status work item 25-05-13

!status received 25-05-13

!assigned author Randy Brukardt

!submitter Randall Brukardt

!priority Low

!difficulty Easy

!qualifier Clarification

!subject Make 10646 non-normative

!summary

Put ISO/IEC 10646 into the Bibliography and remove it from the Normative References clause. Additionally, remove it from any normative uses in the body of the Reference Manual, in favor of Unicode.

!issue

AI22-0073-1 adds a normative reference to the Unicode standard (“The Unicode Consortium. The Unicode Standard, Version 15.0.0[a][b]”). We need this normative reference as we depend upon many of the character classifications of Unicode that are not present in ISO/IEC 10646. (In particular, case classifications and operations.)

ISO/IEC 10646 is essentially a subset of “The Unicode Standard”, and provides many of the same definitions. This poses the possibility that the two standards could conflict in some way, in particular if a future update to Ada modified the versions of these standards used.

As such, it would be preferable if all of the normative character properties used in our documents come from a single Standard. As noted above, we have to use Unicode for some properties, therefore it makes the most sense to use only Unicode for all character properties.

While changing the references from clauses of ISO/IEC 10646 to definitions or sections of Unicode, it appeared that some of the terms that were used since Ada 2005 needed to be updated, for instance “coding space” (should be “codespace”). ISO/IEC 10646 has long used the same terminology as the Unicode Standard, so some terms referenced by Ada were no longer actually defined in the standard it was citing.

!recommendation

(See summary.)

!wording

Delete 1.2(8/5).

Add after 1.2.1(8/5):

ISO/IEC 10646:2020, Information technology — Universal coded character set (UCS)

Modify 2.1(1/5):

The character repertoire for the text of an Ada program consists of the entire [coding space]{codespace} described by [the ]{The Unicode Standard, version 15.0.0}[ISO/IEC 10646:2020 Universal Coded Character Set]. This [coding space]{codespace} is organized in planes, each plane comprising 65536 characters.

[Robin’s note: codespace is defined by definition D9 in The Unicode Standard]

Modify AARM 2.1(1.c/5):

It is our intent to follow the terminology of {The Unicode Standard, version 15.0.0}[ISO/IEC 10646:2020] where appropriate, and to remain compatible with the character classifications defined in A.3, “Character Handling”.

Modify 2.1(3.1/5):

A character is defined by this Reference Manual for each {code point}[cell] in the [coding space]{codespace} described by {The Unicode Standard, version 15.0.0}[ISO/IEC 10646:2020], regardless of whether or not {Unicode}[ISO/IEC 10646:2020] allocates a character to that {code point}[cell].

Modify 2.1(4/5):

The coded representation for characters is implementation defined (it can be a representation that is not defined within {The Unicode Standard, version 15.0.0}[ISO/IEC 10646:2020]). 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. The only characters allowed outside of comments are those in categories other_format, format_effector, and graphic_character.

Add after 2.1(4/5):

AARM Discussion: The code points U+nFFFE and U+nFFFF are defined as noncharacters in The Unicode Standard; they will never be assigned to characters in any future version of Unicode. The code points U+FDD0..U+FDEF are also noncharacters, but are allowed in the text of an Ada program.

[Editor’s note: This is from Robin Leroy (Unicode Liasion); it seems like a useful explanation.]

Modify 2.1(4.1/5):

The semantics of an Ada program whose text is not in Normalization Form C (as defined by {Definition D120}[Clause 22] of {The Unicode Standard, version 15.0.0}[ISO/IEC 10646:2020]) is implementation defined.

Modify 2.1(6.a/5):

Our character classification considers that the {unassigned code points}[cells not allocated] in {The Unicode Standard, version 15.0.0}[ISO/IEC 10646:2020] are graphic characters, except for those whose relative code point in their plane is 16#FFFE# or 16#FFFF#. This seems to provide the best compatibility with future versions of {Unicode}[ISO/IEC 10646], as future characters can already be used in Ada character and string literals.

Modify 2.1(15/5):

The following names are used when referring to certain characters (the first name is that given in {The Unicode Standard, version 15.0.0}[ISO/IEC 10646:2020]):

Modify 2.3(4.1/5):

An identifier shall only contain characters that may be present in Normalization Form KC as defined by {Definition D121}[Clause 22] of {The Unicode Standard, version 15.0.0}[ISO/IEC 10646:2020].

Modify 3.5.2(2/6):

The predefined type Character is a character type having 256 values. Those values correspond to the 256 code points of Row 00 (also known as Latin-1) of the [ISO/IEC 10646:2020] Basic Multilingual Plane (BMP){ of The Unicode Standard, version 15.0.0}. Each of the graphic characters of Row 00 of the BMP has a corresponding character_literal in Character. Each of the nongraphic characters of Row 00 has a corresponding language-defined name, which is not usable as an enumeration literal, but which is usable with the attributes Image, Wide_Image, Wide_Wide_Image, Value, Wide_Value, and Wide_Wide_Value; these names are given in the definition of type Character in A.1, “The Package Standard”, but are set in italics.

Modify 3.5.2(3/6):

The predefined type Wide_Character is a character type having 2**16 values. Those values correspond to the 2**16 code points of the [ISO/IEC 10646:2020] Basic Multilingual Plane (BMP){ of The Unicode Standard, version 15.0.0}. Each of the graphic characters of the BMP has a corresponding character_literal in Wide_Character. The first 256 values of Wide_Character have the same character_literal or language-defined name as defined for Character. Each of the graphic_characters has a corresponding character_literal.

Modify 3.5.2(4/6):

The predefined type Wide_Wide_Character is a character type having 2**32 values. The values with position numbers in the range 0 .. 16#10FFFF# whose values correspond to the 17 * 2**16 code points of the {codespace of The Unicode Standard, version 15.0.0}[ISO/IEC 10646:2020 character set]. Each of the graphic_characters has a corresponding character_literal in Wide_Wide_Character. The first 2**16 values of Wide_Wide_Character have the same character_literal or language-defined name as defined for Wide_Character.

Modify A.1(36.1/5):

-- The declaration of type Wide_Character is based on the standard {Unicode, version 15.0.0}[ISO/IEC 10646:2020] BMP character

 -- set. The first 256 positions have the same contents as type Character. See 3.5.2.

Modify A.1(36.2/5):

-- The declaration of type Wide_Wide_Character is based on the full

-- {Unicode Standard, version 15.0.0}[ISO/IEC 10646:2020] character set. The first 65536 positions have the

-- same contents as type Wide_Character. See 3.5.2.

Modify A.3.2(32.6/5):

True if Item can be present in a string normalized to Normalization Form KC (as defined by {Definition D121}[Clause 22] of{The Unicode Standard, version 15.0.0}[ISO/IEC 10646:2020]){[Redundant:; this includes all characters except those with position 160 (No_Break_Space), 168 ('¨'), 170 ('ª'), 175 ('¯'), 178 ('²'), 179 ('³'), 180 ('´'), 181 ('µ'), 184 ('¸'), 185 ('¹'), 186 ('º'), 188 ('¼'), 189 ('½'), and 190 ('¾')]}[; this includes all characters except those with positions 160, 168, 170, 175, 178, 179, 180, 181, 184, 185, 186, 188, 189, and 190].

Modify A.3.2(60/3):

There are certain characters which are defined to be lower case letters by {Unicode}[ISO 10646] and are therefore allowed in identifiers, but are not considered lower case letters by Ada.Characters.Handling.

Modify A.3.5(33.2/5):

Returns True if the Wide_Character designated by Item has no Decomposition Mapping in the code charts of {The Unicode Standard, version 15.0.0}[ISO/IEC 10646:2020]; otherwise returns False.

Modify AARM A.3.5(33.a/5):

Decomposition Mapping is defined {by Definition D62}[in Clause 33] of {The Unicode Standard, version 15.0.0}[ISO/IEC 10646:2020]. Machine-readable (and normative!) versions of this can be found as Character Decomposition Mapping, described in file http://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt, field 5 (which is the 6th item, Unicode counts from zero).

Modify A.3.5(51.2/5):

Returns True if the Wide_Character designated by Item can be present in a string normalized to Normalization Form KC (as defined by {Definition D121}[Clause 22] of {The Unicode Standard, version 15.0.0}[ISO/IEC 10646:2020]), otherwise returns False.

Modify A.3.5(61.2/5):

Returns the Wide_Character whose code point is given by the first value of its Decomposition Mapping in the code charts of {The Unicode Standard, version 15.0.0}[ISO/IEC 10646:2020] if any; returns Item otherwise.

Modify A.3.5(63/5):

The results returned by these functions can depend on which particular version of {Unicode or }ISO/IEC 10646 is supported by the implementation (see 2.1).

Modify A.4.6(8/5):

There are certain characters which are defined to be lower case letters by {Unicode}[ISO/IEC 10646] and are therefore allowed in identifiers, but are not considered lower case letters by Ada.Strings.Maps.Constants.

!discussion

This change should not change the definition of the properties of any character. As such, it should not have any effect on any (correct) existing implementation or program.

!corrigendum 1.2(8/5)

@ddel

ISO/IEC 10646:2020, @i{Information technology @emdash Universal coded character set (UCS)}

!corrigendum 1.2.1(8/5)

@dinsa

ISO/IEC 9899:2018, @i{Information technology @emdash Programming languages @emdash C}

@dinst

ISO/IEC 10646:2020, @i{Information technology @emdash Universal coded character set (UCS)}

!corrigendum 2.1(1/5)

@drepl

The character repertoire for the text of an Ada program consists of the entire coding space described by the ISO/IEC 10646:2020 Universal Coded Character Set. This 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 codespace described by The Unicode Standard, version 15.0.0. This codespace is organized in @i{planes}, each plane comprising 65536 characters.

!corrigendum 2.1(3.1/5)

@drepl

A @fa{character} is defined by this Reference Manual for each cell in the coding space described by ISO/IEC 10646:2020, regardless of whether or not ISO/IEC 10646:2020 allocates a character to that cell.

@dby

A @fa{character} is defined by this Reference Manual for each code point in the codespace described by The Unicode Standard, version 15.0.0, regardless of whether or not Unicode allocates a character to that code point.

!corrigendum 2.1(4/5)

@drepl

The coded representation for characters is implementation defined (it can be a representation that is not defined within ISO/IEC 10646:2020). 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. The only characters allowed outside of comments are those in categories @fa{other_format}, @fa{format_effector}, and @fa{graphic_character}.

@dby

The coded representation for characters is implementation defined (it can be a representation that is not defined within The Unicode Standard, version 15.0.0). 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. The only characters allowed outside of comments are those in categories @fa{other_format}, @fa{format_effector}, and @fa{graphic_character}.

!corrigendum 2.1(4.1/5)

@drepl

The semantics of an Ada program whose text is not in Normalization Form C (as defined by Clause 22 of ISO/IEC 10646:2020) is implementation defined.

@dby

The semantics of an Ada program whose text is not in Normalization Form C (as defined by Definition D120 of The Unicode Standard, version 15.0.0) is implementation defined.

!corrigendum 2.1(15/5)

@drepl

The following names are used when referring to certain characters (the first name is that given in ISO/IEC 10646:2020):

@dby

The following names are used when referring to certain characters (the first name is that given in The Unicode Standard, version 15.0.0):

!corrigendum 2.3(4.1/5)

@drepl

An identifier shall only contain characters that may be present in Normalization Form KC as defined by Clause 22 of ISO/IEC 10646:2020.

@dby

An @fa{identifier} shall only contain characters that may be present in Normalization Form KC as defined by Definition D121 of The Unicode Standard, version 15.0.0.

!corrigendum 3.5.2(2/6)

@drepl

The predefined type Character is a character type having 256 values. Those values correspond to the 256 code points of Row 00 (also known as Latin-1) of the ISO/IEC 10646:2020 Basic Multilingual Plane (BMP). Each of the graphic characters of Row 00 of the BMP has a corresponding @fa{character_literal} in Character. Each of the nongraphic characters of Row 00 has a corresponding language-defined name, which is not usable as an enumeration literal, but which is usable with the attributes Image, Wide_Image, Wide_Wide_Image, Value, Wide_Value, and Wide_Wide_Value; these names are given in the definition of type Character in @ref{A.1}, “The Package Standard”, but are set in @i{italics}.

@dby

The predefined type Character is a character type having 256 values. Those values correspond to the 256 code points of Row 00 (also known as Latin-1) of the Basic Multilingual Plane (BMP) of The Unicode Standard, version 15.0.0. Each of the graphic characters of Row 00 of the BMP has a corresponding @fa{character_literal} in Character. Each of the nongraphic characters of Row 00 has a corresponding language-defined name, which is not usable as an enumeration literal, but which is usable with the attributes Image, Wide_Image, Wide_Wide_Image, Value, Wide_Value, and Wide_Wide_Value; these names are given in the definition of type Character in @ref{A.1}, “The Package Standard”, but are set in @i{italics}.

!corrigendum 3.5.2(3/6)

@drepl

The predefined type Wide_Character is a character type having 2**16 values. Those values correspond to the 2**16 code points of the ISO/IEC 10646:2020 Basic Multilingual Plane (BMP). Each of the graphic characters of the BMP has a corresponding @fa{character_literal} in Wide_Character. The first 256 values of Wide_Character have the same @fa{character_literal} or language-defined name as defined for Character. Each of the @fa{graphic_character}s has a corresponding @fa{character_literal}.

@dby

The predefined type Wide_Character is a character type having 2**16 values. Those values correspond to the 2**16 code points of the Basic Multilingual Plane (BMP) of The Unicode Standard, version 15.0.0. Each of the graphic characters of the BMP has a corresponding @fa{character_literal} in Wide_Character. The first 256 values of Wide_Character have the same @fa{character_literal} or language-defined name as defined for Character. Each of the @fa{graphic_character}s has a corresponding @fa{character_literal}.

!corrigendum 3.5.2(4/6)

@drepl

The predefined type Wide_Wide_Character is a character type having 2**32 values. The values with position numbers in the range 0 .. 16#10FFFF# correspond to the 17 * 2**16 code points of the ISO/IEC 10646:2020 character set. Each of the @fa{graphic_character}s has a corresponding @fa{character_literal} in Wide_Wide_Character. The first 2**16 values of Wide_Wide_Character have the same @fa{character_literal} or language-defined name as defined for Wide_Character.

@dby

The predefined type Wide_Wide_Character is a character type having 2**32 values. The values with position numbers in the range 0 .. 16#10FFFF# correspond to the 17 * 2**16 code points of the codespace of The Unicode Standard, version 15.0.0. Each of the @fa{graphic_character}s has a corresponding @fa{character_literal} in Wide_Wide_Character. The first 2**16 values of Wide_Wide_Character have the same @fa{character_literal} or language-defined name as defined for Wide_Character.

!corrigendum A.1(36.1/5)

@drepl

@xcode{   --@ft{@i{ The declaration of type Wide_Character is based on the standard ISO/IEC 10646:2020 BMP character}}

   --@ft{@i{ set. The first 256 positions have the same contents as type Character. See @ref{3.5.2}.}}

   @b{type} Wide_Character @b{is} (@ft{@i{nul}}, @ft{@i{soh}} ... @ft{@i{Hex_0000FFFE}}, @ft{@i{Hex_0000FFFF}});}

@dby

@xcode{   --@ft{@i{ The declaration of type Wide_Character is based on the standard Unicode, version 15.0.0 BMP character}}

   --@ft{@i{ set. The first 256 positions have the same contents as type Character. See @ref{3.5.2}.}}

   @b{type} Wide_Character @b{is} (@ft{@i{nul}}, @ft{@i{soh}} ... @ft{@i{Hex_0000FFFE}}, @ft{@i{Hex_0000FFFF}});}

!corrigendum A.1(36.2/5)

@drepl

@xcode{   --@ft{@i{ The declaration of type Wide_Wide_Character is based on the full}}

   --@ft{@i{ ISO/IEC 10646:2020 character set. The first 65536 positions have the}}

   --@ft{@i{ same contents as type Wide_Character. See @ref{3.5.2}.}}

   @b{type} Wide_Wide_Character @b{is} (@ft{@i{nul}}, @ft{@i{soh}} ... @ft{@i{Hex_7FFFFFFE}}, @ft{@i{Hex_7FFFFFFF}});

   @b{for} Wide_Wide_Character'Size @b{use} 32;}

@dby

@xcode{   --@ft{@i{ The declaration of type Wide_Wide_Character is based on the full}}

   --@ft{@i{ Unicode Standard, version 15.0.0 character set. The first 65536 positions have the}}

   --@ft{@i{ same contents as type Wide_Character. See @ref{3.5.2}.}}

   @b{type} Wide_Wide_Character @b{is} (@ft{@i{nul}}, @ft{@i{soh}} ... @ft{@i{Hex_7FFFFFFE}}, @ft{@i{Hex_7FFFFFFF}});

   @b{for} Wide_Wide_Character'Size @b{use} 32;}

!corrigendum A.3.2(32.6/5)

@drepl

@xhang{@xterm{Is_NFKC}True if Item can be present in a string normalized to Normalization Form KC (as defined by Clause 22 of ISO/IEC 10646:2020); this includes all characters except those with positions 160, 168, 170, 175, 178, 179, 180, 181, 184, 185, 186, 188, 189, and 190.}

@dby

@xhang{@xterm{Is_NFKC}True if Item can be present in a string normalized to Normalization Form KC (as defined by Definition D121 of The Unicode Standard, version 15.0.0); this includes all characters except those with position 160 (No_Break_Space), 168 (‘@unicode{168}’), 170 ('@unicode{170}'), 175 ('@unicode{175}'), 178 ('@unicode{178}'), 179 ('@unicode{179}'), 180 ('@unicode{180}'), 181 ('@unicode{181}'), 184 ('@unicode{184}'), 185 ('@unicode{185}'), 186 ('@unicode{186}'), 188 ('@unicode{188}'), 189 ('@unicode{189}'), and 190 ('@unicode{190}').}

!corrigendum A.3.2(60/3)

@drepl

@xindent{@s9{NOTE 3 @  There are certain characters which are defined to be lower case letters by ISO 10646 and are therefore allowed in identifiers, but are not considered lower case letters by Ada.Characters.Handling.}}

@dby

@xindent{@s9{NOTE 3 @  There are certain characters which are defined to be lower case letters by Unicode and are therefore allowed in identifiers, but are not considered lower case letters by Ada.Characters.Handling.}}

!corrigendum A.3.5(33.2/5)

@drepl

@xindent{Returns True if the Wide_Character designated by Item has no Decomposition Mapping in the code charts of ISO/IEC 10646:2020; otherwise returns False.}

@dby

@xindent{Returns True if the Wide_Character designated by Item has no Decomposition Mapping in the code charts of The Unicode Standard, version 15.0.0; otherwise returns False.}

!corrigendum A.3.5(51.2/5)

@drepl

@xindent{Returns True if the Wide_Character designated by Item can be present in a string normalized to Normalization Form KC (as defined by Clause 22 of ISO/IEC 10646:2020), otherwise returns False.}

@dby

@xindent{Returns True if the Wide_Character designated by Item can be present in a string normalized to Normalization Form KC (as defined by Definition D121 of The Unicode Standard, version 15.0.0), otherwise returns False.}

!corrigendum A.3.5(61.2/5)

@drepl

@xindent{Returns the Wide_Character whose code point is given by the first value of its Decomposition Mapping in the code charts of ISO/IEC 10646:2020 if any; returns Item otherwise.}

@dby

@xindent{Returns the Wide_Character whose code point is given by the first value of its Decomposition Mapping in the code charts of The Unicode Standard, version 15.0.0 if any; returns Item otherwise.}

!corrigendum A.3.5(63/5)

@drepl

@xindent{@s9{NOTE 1 @  The results returned by these functions can depend on which particular version of ISO/IEC 10646 is supported by the implementation (see @ref{2.1}).}}

@dby

@xindent{@s9{NOTE 1 @  The results returned by these functions can depend on which particular version of Unicode or ISO/IEC 10646 is supported by the implementation (see @ref{2.1}).}}

!corrigendum A.4.6(8/5)

@drepl

@xindent{@s9{NOTE @  There are certain characters which are defined to be lower case letters by ISO/IEC 10646 and are therefore allowed in identifiers, but are not considered lower case letters by Ada.Strings.Maps.Constants.}}

@dby

@xindent{@s9{NOTE @  There are certain characters which are defined to be lower case letters by Unicode and are therefore allowed in identifiers, but are not considered lower case letters by Ada.Strings.Maps.Constants.}}

!ACATS test

This change should not affect any implementation, as the underlying definitions are believed to be the same. As such, no ACATS tests are needed.

!appendix

This issue was raised by the Project Editor with the Unicode liaison to SC 22 after the construction and approval of AI22-0073-1. The Unicode liaison agreed at that time that making this change was a good idea, but not critical. The AI has spent the intervening years on the Project Editor’s lengthy to-do list.

 

[a]It might be useful to bump this to 16.0, because in 16.0 the Unicode Standard moved to HTML, so we can link to individual definitions in the AARM, e.g., https://unicode.org/versions/Unicode16.0.0/core-spec/chapter-3/#G40097 for Decomposition mapping.

16.0 is synchronized with ISO/IEC 10646:2000/Amd 2 (under publication, https://www.iso.org/standard/85287.html).

[b]It seems likely that the number would be made current when the next Revision is actually nearing completion. And changing this now would require redoing most of the changes from AI22-0073-1. So I think we should wait, although we could mention this point in the !Discussion.