Version 1.2 of ai05s/ai05-0016-1.txt
!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)
Replace the paragraph:
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.
by:
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.
!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.
****************************************************************
Questions? Ask the ACAA Technical Agent