!standard C.5(1) 13-06-07 AI12-0072-1/01 !standard C.5(5) !standard C.5(7/2) !standard C.5(8) !class binding interpretation !status work item 13-06-07 !status received 13-05-03 !priority Low !difficulty Easy !qualifier Error !subject Missing rules for Discard_Names aspect !summary Discard_Names is an aspect, with typical rules. !question Discard_Names is not on the list of language-defined aspects and nothing in C.5 says that it can be used as an aspect name, but AARM Note C.5(6.a/3) says it is a language-defined aspect. Which is it? (It's an aspect.) !recommendation (See !summary.) !wording Change the title of C.5 to: Aspect and Pragma Discard_Names Add after C.5(1): Static Semantics For a nonderived enumeration Redundant[first] subtype, a tagged Redundant[first] subtype, or an exception, the following language-defined representation aspect may be specified: Discard_Names The type of aspect Discard_Names is Boolean. If directly specified, the aspect_definition shall be a static expression. If not specified (including by inheritance), the aspect is False. [Also, make sure this aspect gets added to the index of aspects in K.1: Discard_Names -- Reduces storage for names associated with an entity.] Modify C.5(5): The local_name (if present) shall denote a nonderived enumeration first subtype, a tagged first subtype, or an exception. The pragma [applies to]{specifies that the aspect Discard_Name for} the type or exception {has the value True}. Without a local_name, the pragma [applies to]{specifies that} all such entities declared after the pragma, within the same declarative region{ have the value True for aspect Discard_Names}. Alternatively, the pragma can be used as a configuration pragma. [If the pragma applies to a type, then it applies also to all descendants of the type.] [Editor's note: We don't need the last sentence because normal aspect inheritance applies and has that effect.] Modify C.5(7/2): If the [pragma applies to]{aspect Discard_Names is True for} an enumeration type, then the semantics of the Wide_Wide_Image and Wide_Wide_Value attributes are implementation defined for that type; the semantics of Image, Wide_Image, Value, and Wide_Value are still defined in terms of Wide_Wide_Image and Wide_Wide_Value. In addition, the semantics of Text_IO.Enumeration_IO are implementation defined. If the [pragma applies to]{aspect Discard_Names is True for} a tagged type, then the semantics of the Tags.Wide_Wide_Expanded_Name function are implementation defined for that type; the semantics of Tags.Expanded_Name and Tags.Wide_Expanded_Name are still defined in terms of Tags.Wide_Wide_Expanded_Name. If the [pragma applies to]{aspect Discard_Names is True for} an exception, then the semantics of the Exceptions.Wide_Wide_Exception_Name function are implementation defined for that exception; the semantics of Exceptions.Exception_Name and Exceptions.Wide_Exception_Name are still defined in terms of Exceptions.Wide_Wide_Exception_Name. Modify C.5(8): If the [pragma applies to]{aspect Discard_Names is True for} an entity, then the implementation should reduce the amount of storage used for storing names associated with that entity. !discussion The original intent was that blanket rules in 13.1 and 13.1.1 would be sufficient to specify the rules for aspect pragmas. But eventually every such pragma except this one got explicit rules. It seems weird that this solitary pragma depends on the blanket rules (enough that it failed to get added to the index of aspects). In addition, it's not clear that the blanket rules define the type of the aspect and any requirements on the expression. Finally, if we add the aspect to the aspect index, it would be bad if there was no text describing the aspect at the target of that index entry. So, for all of these reasons, we define the aspect here, and then define the pragma in terms of the aspect in the usual way. It is not the intent of these changes to change the effect of pragma Discard_Names in any way. !ACATS Test A test of aspect Discard_Names should be created (possibly an existing pragma test could be used as a basis). !ASIS No ASIS effect. !appendix From: Randy Brukardt Sent: Friday, May 3, 2013 7:42 PM AARM Note C.5(6.a/3) says: Representation pragmas automatically specify aspects of the same name, so Discard_Names can be used as an aspect_mark in an aspect_specification instead of using the pragma on individual entities. Unlike a lot of other pragmas, this one was not obsolesced because it can also act as a configuration pragma (and there is no such thing as a configuration aspect - what would it be an aspect of?). As such, the text of this subclause was unchanged from Ada 2005. However, I note that this aspect didn't make it into the list of language-defined aspects, presumably because there is no text defining that it exists (unlike virtually every other aspect). I presume that its being omitted from the list of language-defineed aspects is an oversight. However, it probably would be good to put some text in C.5 mentioning that this aspect exists. Otherwise, someone coming from the list of aspects to C.5 is going to be mightly confused (the rule that makes it exist is in 13.1, after all). Thoughts? If there is agreement that this should be done, I'll propose some wording and write up a ramification AI to do it. (It's a bit more than a pure presentation change; I'd write it as a confirmation AI, but those don't allow any associated wording changes.) ****************************************************************