!standard 4.2(6) 19-04-01 AI12-0325-1/01 !standard 4.2(10) !standard 4.2(11) !standard 4.2.1(0) !reference AI12-0295-1 !class Amendment 19-04-01 !status Amendment 1-2012 19-04-01 !status work item 19-04-01 !status received 15-03-20 !priority Low !difficulty Easy !subject Definition of String Type !summary "String Type" is defined as in Ada 2012. In particular, a type with a specified String_Literal aspect is not a string type. !problem AI12-0295-1 defines "String type" to include types that have a defined String_Literal aspect. This causes a number of issues: (1) We don't change "numeric type" this way, so the wording in 4.2 and 4.2.1 is oddly different for numeric and string literals. (2) There are many rules that we only want to apply to Ada 2012 string types. For instance, we don't want static expressions of types with user-defined string literals. This leads to rather convuluted descriptions of rules, such as the proposed 4.2(11/5): The evaluation of a string_literal that is a primary and has an expected type that is a one-dimensional array type with a character type as its component type, yields an array value ... !proposal (See Summary.) !wording [Author's note: This wording is relative to the Ada 2012 wording, not the changed wording from AI12-0295-1.] [Editor's note: These changes are found in Draft 19 of the RM.] There is no change to 3.6.3(1) (unlike AI12-0295-1). Modify 4.2(4): The expected type for a primary that is a string_literal shall be a single string type{ or a type with a specified String_Literal aspect (see 4.2.1)}. [Author's note: This is the only new wording change; all of the others are simplifications.] Modify 4.2(6): {If the expected type for a string_literal is a string type, then} [F]{f}or each character of [a]{the} string_literal [with a given expected string type,] there shall be a corresponding defining_character_literal of the component type of the expected string type. Modify 4.2(10): The evaluation of a string_literal that is a primary {and has an expected type that is a string type,} yields an array value containing the value of each character of the sequence of characters of the string_literal, as defined in 2.6. The bounds of this array value are determined according to the rules for positional_array_aggregates (see 4.3.3), except that for a null string literal, the upper bound is the predecessor of the lower bound. {Redundant[In other cases, the effect of evaluating a string_literal is determined by the String_Literal aspect that applies (see 4.2.1).]} [Author's note: The last sentence echos one found in 4.2(9); it was missing from AI12-0295-1 and reviewers complained about that.] Modify 4.2(11): For the evaluation of a string_literal of {a string} type T, a check is made that the value of each character of the string_literal belongs to the component subtype of T. For the evaluation of a null string literal {of a string type}, a check is made that its lower bound is greater than the lower bound of the base range of the index type. The exception Constraint_Error is raised if either of these checks fails. [Author's note: The part about restricting the check for null string literals to (Ada 2012) string types is missing from AI12-0295-1. It certainly can't apply to types with String_Literal aspects, as those probably are not arrays and thus have no bounds.] 4.2.1(5/5) and 4.2.1(9/5) are unchanged from the AI12-0295-1 versions. The AI12-0295-1 4.2.1(6/5) paragraph is omitted. In 4.2.1(7/5), replace the String_Literal sentence with: The String_Literal aspect shall not be specified for a type T if the full view of T is a string type. There is no change to 4.9(26/3) (unlike AI12-0295-1). !discussion These wording changes do not make any semantic change to the features defined in AI12-0295-1. !corrigendum 4.2(4) @drepl The expected type for a @fa that is a @fa shall be a single string type. @dby The expected type for a @fa that is a @fa shall be a single string type or a type with a specified String_Literal aspect (see 4.2.1). !corrigendum 4.2(6) @drepl For each character of a @fa with a given expected string type, there shall be a corresponding @fa of the component type of the expected string type. @dby If the expected type for a string_literal is a string type, then for each character of the @fa there shall be a corresponding @fa of the component type of the expected string type. !corrigendum 4.2(10) @drepl The evaluation of a @fa that is a @fa yields an array value containing the value of each character of the sequence of characters of the @fa, as defined in 2.6. The bounds of this array value are determined according to the rules for @fas (see 4.3.3), except that for a null string literal, the upper bound is the predecessor of the lower bound. @dby The evaluation of a @fa that is a @fa and has an expected type that is a string type, yields an array value containing the value of each character of the sequence of characters of the @fa, as defined in 2.6. The bounds of this array value are determined according to the rules for @fas (see 4.3.3), except that for a null string literal, the upper bound is the predecessor of the lower bound. In other cases, the effect of evaluating a @fa is determined by the String_Literal aspect that applies (see 4.2.1). !corrigendum 4.2(11) @drepl For the evaluation of a @fa of type @i, a check is made that the value of each character of the @fa belongs to the component subtype of @i. For the evaluation of a null string literal, a check is made that its lower bound is greater than the lower bound of the base range of the index type. The exception Constraint_Error is raised if either of these checks fails. @dby For the evaluation of a @fa of a string type @i, a check is made that the value of each character of the @fa belongs to the component subtype of @i. For the evaluation of a null string literal of a string type, a check is made that its lower bound is greater than the lower bound of the base range of the index type. The exception Constraint_Error is raised if either of these checks fails. !corrigendum 4.2.1(0) @dinsc Just enough to cause a conflict; the real changes are in the conflict file. !ASIS None here, since this is just changing the presentation of the change. !ACATS test No tests needed for this AI, since this is just a presentation change. !appendix From: Steve Baird Sent: Thursday, March 7, 2019 3:51 PM [Part of Steve's RM review - Editor.] 3.6.3 - ok We've got "There are three predefined String types", which would be confusing (does that mean "at least three" or "exactly three" ?) if some other predefined package defined a type with the String_Literal aspect specified, but that does not appear to be the case. 4.2 ... In 9/5, we've got " In other cases, the effect of evaluating a numeric literal is determined by the Integer_Literal or Real_Literal aspect that applies (see 4.2.1)." That seems good, but there is no analogous text for string literals. It seems messy having three slightly-different uses of "one-dimensional array type" in this section. Similarly, the rule in 4.2 about "T is a string type (in the absence of the String_Literal aspect specification)." seems awkward. It looks like we need a term corresponding to the *old* definition of "string type". **************************************************************** From: Randy Brukardt Sent: Wednesday, March 20, 2019 12:08 AM ... >3.6.3 - ok > We've got "There are three predefined String types", which would be > confusing (does that mean "at least three" or "exactly three" ?) if some > other predefined package defined a type with the String_Literal aspect > specified, but that does not appear to be the case. I griped about calling types with a String_Literal aspect a "string type", since most of the properties of a string type don't apply. Tucker seemed to feel strongly the other way, since he changed all of those other places instead of getting rid of this silly definition after my complaint. As such, we're living with this, and it's hard to get too worked up about how many string types there actually are. ... > In 9/5, we've got > " In other cases, the effect of evaluating a numeric literal is determined > by the Integer_Literal or Real_Literal aspect that applies (see 4.2.1)." > That seems good, but there is no analogous text for string literals. That happens because any type with a String_Literal is a string type, so there's no sane way to write such a rule. As noted above, I think that is madness but I lost that discussion. In any case, we don't need to say anything here. (The 9/5 rule could and probably should be marked Redundant[]). > It seems messy having three slightly-different uses of "one-dimensional > array type" in this section. Similarly, the rule in 4.2 about > "T is a string type (in the absence of the String_Literal aspect > specification)." seems awkward. It looks like we need a term corresponding > to the *old* definition of "string type". No, we *only* need the old definition of "string type". There's no reason that I can see to have a term for types that have user-defined literals. And we are just fine not changing the definition of numeric types, why are strings (and characters, in the AI we didn't adopt) different?? But again, I lost that argument previously and I am uninterested in trying to argue it again, especially as the AI needed would be nearly as big as the original AI12-0295-1 (*all* of the wording in AI12-0295-1 would need to change). If you want to propose such an AI, go ahead, but I don't have the time or energy to do so. **************************************************************** From: Steve Baird Sent: Thursday, March 21, 2019 8:07 PM ... > I griped about calling types with a String_Literal aspect a "string > type", since most of the properties of a string type don't apply. > Tucker seemed to feel strongly the other way, since he changed all of > those other places instead of getting rid of this silly definition after my complaint. > > As such, we're living with this, and it's hard to get too worked up > about how many string types there actually are. Insufficiently broken. Let's stick with what we have now. ... > No, we *only* need the old definition of "string type". There's no reason that > I can see to have a term for types that have user-defined literals. And we are > just fine not changing the definition of numeric types, why are strings (and > characters, in the AI we didn't adopt) different?? But again, I lost that > argument previously and I am uninterested in trying to argue it again, > especially as the AI needed would be nearly as big as the original > AI12-0295-1 (*all* of the wording in AI12-0295-1 would need to change). If you > want to propose such an AI, go ahead, but I don't have the time or energy to > do so. I do not plan to propose any such AI. **************************************************************** From: Tucker Taft Sent: Sunday, March 24, 2019 11:56 PM > I griped about calling types with a String_Literal aspect a "string > type", since most of the properties of a string type don't apply. > Tucker seemed to feel strongly the other way, since he changed all of > those other places instead of getting rid of this silly definition after my > complaint. I don't feel as strongly as you imply. In fact, I don't remember reading your complaint, so I might have just missed it, or not fully appreciated the implications. > As such, we're living with this, and it's hard to get too worked up > about how many string types there actually are. I am amenable to *not* generalizing the notion of a "string type." I felt it simplified things, but if in fact it complicates things, then let's get rid of it. **************************************************************** [Editor's note: After reading the above, Steve changed his position and (privately) asked for an AI to be created with these changes.] ***************************************************************