!standard 4.3.1(15) 06-06-22 AI05-0016-1/01 !class binding interpretation 06-06-22 !status work item 06-06-22 !status received 06-06-19 !priority Medium !difficulty Medium !qualifier Error !subject Others => <> can be used in place of null record !summary Others => <> can be used in place of null record. !question "Programming in Ada 2005" says that "The aggregate for the (null) value ... can be written as (null record) or even as (others => <>)." But 4.3.1(15) says that if no components are needed, then "null record shall appear". "Shall" here implies that there is no alternative. It is highly irregular that others => <> can represent no components for any record type except a record type that has no components at all. Is this intended? (No.) !recommendation Others => <> can be used in place of null record. !wording Modify 4.3.1(15): If there are no components needed in a given record_component_association_list, then the reserved words null record [shall] {may} appear rather than a list of record_component_associations. AARM Note: If no components are needed and null record is not used, the record_component_association must necessarily be others => <>, as that is the only record_component_association that does not require an associated component. !discussion This appears to be a rule whose change was missed during the Amendment work. !corrigendum 4.3.1(15) @drepl If there are no components needed in a given @fa, then the reserved words @b shall appear rather than a list of @fas. @dby If there are no components needed in a given @fa, then the reserved words @b may appear rather than a list of @fas. !ACATS test An ACATS C-Test should be created to test that this works. !appendix From: Randy Brukardt Date: Monday, June 19, 2006 6:52 PM A question on comp.lang.ada shows what I think is a bug in the Amendment. The questioner points out that John's book says: "The aggregate for the (null) value ... can be written as (null record) or even as (others => <>)." But 4.3.1(15) appears to conflict: "If there are no components needed in a given record_component_association_list, then the reserved words null record shall appear rather than a list of record_component_associations." My expectation here matches what John wrote: (null record) and (others => <>) are interchangeable. Indeed, I prefer the latter, because it looks like an aggregate, whereas "null record" looks like a type declaration that got dropped into any expression. It also would be odd that (others => <>) could be used for any type except for a null record. It's better if it always represents a default initialized array or record type. So I think that we forgot to modify 4.3.1(15) to allow others => <>. The wording should be something like: "If there are no components needed in a given record_component_association_list, then the reserved words null record may appear rather than a list of record_component_associations." (That is, "null record" may appear rather than a list, which necessarily would be an "others => <>", as that is the only record_component_association which does not require an associated component.) Thoughts? **************************************************************** From: Erhard Ploedereder Date: Monday, June 19, 2006 7:19 PM Many. Go back to approx Jan/Feb 2005 and look for a thread entitled "new aggregate stuff" and its predecessors. It discussed the point at nauseam and it had a safety argument why "others => <>" is bad news. It definitely is not an unintentional oversight. **************************************************************** From: Randy Brukardt Date: Monday, June 19, 2006 9:45 PM > Many. Go back to approx Jan/Feb 2005 and look for a thread entitled > "new aggregate stuff" and its predecessors. It discussed the point > at nauseam and it had a safety argument why "others => <>" is bad news. Yes, but that's about "others => <>" in general. And the ARG decided that "others => <>" is not bad news: "others => <>" is allowed to represent no components in every record context, *except* for null records. That seems inconsisent. Opinions about "others => <>" aren't particularly relevant; we're surely not removing it. In any case, it's useful if you don't want or care about coverage checking (i.e., just default initialize this item). > It definitely is not an unintentional oversight. It's certainly an unintentional oversight from my perspective, because I *wrote* this wording (during the integration of the AI on aggregates of private types, which was later dropped) and did not notice the effect of 4.3.1(15). If I had, I certainly would have recommended a change to its wording. Then it at least would have been discussed; there is no evidence that we ever discussed this particular point in any forum. It should be noted that AI-287 is quite clear that the intent is that "others => <>" match a null record type. The recommended wording for 4.3.1(16.a) given in the AI ends "An others choice with a <> can match a null record type or a null extension". (Thanks to Bob for pointing this out.) **************************************************************** From: Tucker Taft Date: Tuesday, June 20, 2006 7:28 AM I would agree with Randy that it was an oversight. (others => <>) should be permitted for a null record. I agree with Erhard that we had long debates about allowing others => <> in general, but Randy is right that we ultimately decided to allow it. Certainly the "danger" associated with others => <> is minimal in the case of a null record! **************************************************************** From: Robert Dewar Date: Tuesday, June 20, 2006 7:35 AM I agree with Tuck and Randy, this is a typo in the RM :-) Obviously this should be allowed. **************************************************************** From: Edmond Schonberg Date: Tuesday, June 20, 2006 7:43 AM > "others => <>" is allowed to represent no > components in every record context, *except* for null records. That > seems inconsisent. This IS inconsistent, and counter-intuitive. others => <> must apply to null records. **************************************************************** From: Robert Dewar Date: Tuesday, June 20, 2006 8:16 AM therefore it already does (remember Robert's rule: the RM cannot be used to derive any obviosuly wrong result :-)) **************************************************************** From: John Barnes Date: Tuesday, June 20, 2006 8:44 AM > Many. Go back to approx Jan/Feb 2005 and look for a thread entitled > "new aggregate stuff" and its predecessors. It discussed the point > at nauseam and it had a safety argument why "others => <>" is bad news. But that was all about the private type stuff. That was discussed on that snowy day in Paris and we removed the use of <> for private types. I had to remove a whole lot of rationale as a consequence. **************************************************************** From: Pascal Leroy Date: Monday, July 10, 2006 4:35 AM > I would agree with Randy that it was an oversight. > (others => <>) should be permitted for a null record. > I agree with Erhard that we had long debates about > allowing others => <> in general, but Randy is right > that we ultimately decided to allow it. Certainly > the "danger" associated with others => <> is minimal > in the case of a null record! Just to beat a dead horse: (others => <>) should definitely be permitted, otherwise we have a generic contract model problem. Consider a formal derived tagged type, whose ancestor is a null record. The actual may or may not be a null record. Now if in the generic body you write (others => <>), is it legal or not? Surely we don't want to assume the worst here. ****************************************************************