Annotated Ada Reference ManualLegal Information
Contents   Index   References   Search   Previous   Next 

4.1.4 Attributes

[An attribute is a characteristic of an entity that can be queried via an attribute_reference or a range_attribute_reference.]


attribute_reference ::= prefix'attribute_designator
{AI05-0004-1} attribute_designator ::= 
  | Access | Delta | Digits | Mod
range_attribute_reference ::= prefix'range_attribute_designator
range_attribute_designator ::= Range[(static_expression)]

Name Resolution Rules

In an attribute_reference, if the attribute_designator is for an attribute defined for (at least some) objects of an access type, then the prefix is never interpreted as an implicit_dereference; otherwise (and for all range_attribute_references), if the type of the name within the prefix is of an access type, the prefix is interpreted as an implicit_dereference. Similarly, if the attribute_designator is for an attribute defined for (at least some) functions, then the prefix is never interpreted as a parameterless function_call; otherwise (and for all range_attribute_references), if the prefix consists of a name that denotes a function, it is interpreted as a parameterless function_call.
Discussion: The first part of this rule is essentially a "preference" against implicit dereference, so that it is possible to ask for, say, 'Size of an access object, without automatically getting the size of the object designated by the access object. This rule applies to 'Access, 'Unchecked_Access, 'Size, and 'Address, and any other attributes that are defined for at least some access objects.
The second part of this rule implies that, for a parameterless function F, F'Address is the address of F, whereas F'Size is the size of the anonymous constant returned by F.
We normally talk in terms of expected type or profile for name resolution rules, but we don't do this for attributes because certain attributes are legal independent of the type or the profile of the prefix prefix.
{AI95-00114-01} Other than the rules given above, the Name Resolution Rules for the prefix of each attribute are defined as Name Resolution Rules for that attribute. If no such rules are defined, then no context at all should be used when resolving the prefix. In particular, any knowledge about the kind of entities required must not be used for resolution unless that is required by Name Resolution Rules. This matters in obscure cases; for instance, given the following declarations: 
  function Get_It return Integer is ... -- (1)
  function Get_It return Some_Record_Type is ... -- (2)
the following attribute_reference cannot be resolved and is illegal: 
  if Get_It'Valid then
{AI05-0005-1} even though the Valid attribute is only defined for objects of scalar types, and thus cannot be applied to the result of function (2). That information cannot be used to resolve the prefix. The same would be true if (2) had was been a procedure; even though the procedure does not denote an object, the attribute_reference is still illegal. 
The expression, if any, in an attribute_designator or range_attribute_designator is expected to be of any integer type. 

Legality Rules

The expression, if any, in an attribute_designator or range_attribute_designator shall be static. 

Static Semantics

{AI05-0006-1} An attribute_reference denotes a value, an object, a subprogram, or some other kind of program entity. For an attribute_reference that denotes a value or an object, if its type is scalar, then its nominal subtype is the base subtype of the type; if its type is tagged, its nominal subtype is the first subtype of the type; otherwise, its nominal subtype is a subtype of the type without any constraint or null_exclusion. Similarly, unless explicitly specified otherwise, for an attribute_reference that denotes a function, when its result type is scalar, its result subtype is the base subtype of the type, when its result type is tagged, the result subtype is the first subtype of the type, and when the result type is some other type, the result subtype is a subtype of the type without any constraint or null_exclusion.
Ramification: The attributes defined by the language are summarized in K.2. Implementations can define additional attributes. 
Discussion: {AI05-0006-1} The nominal subtype is primarily a concern when an attribute_reference, or a call on an attribute_reference, is used as the expression of a case statement, due to the full coverage requirement based on the nominal subtype. For nondiscrete cases, we define the nominal subtype mainly for completeness. Implementations may specify otherwise for implementation-defined attribute functions.
The rule is written to match the meaning of the italicized T in the definition of attributes such as Input; see 4.5.1. 
To be honest: {AI05-0006-1} We don't worry about the fact that “base subtype” is not explicitly defined for the universal types. Since it is not possible to constrain a universal numeric type, all subtypes are unconstrained, and hence can be considered base subtypes. The wording above could be altered to bypass this issue, but it doesn't seem necessary, since universal integer is handled specially in the rules for case expression full coverage, and we don't allow user-defined functions for attribute functions whose result type is universal. 
[A range_attribute_reference X'Range(N) is equivalent to the range X'First(N) .. X'Last(N), except that the prefix is only evaluated once. Similarly, X'Range is equivalent to X'First .. X'Last, except that the prefix is only evaluated once.]

Dynamic Semantics

The evaluation of an attribute_reference (or range_attribute_reference) consists of the evaluation of the prefix.

Implementation Permissions

 {8652/0015} {AI95-00093-01} An implementation may provide implementation-defined attributes; the identifier for an implementation-defined attribute shall differ from those of the language-defined attributes unless supplied for compatibility with a previous edition of this International Standard.
Implementation defined: Implementation-defined attributes.
Ramification: They cannot be reserved words because reserved words are not legal identifiers.
The semantics of implementation-defined attributes, and any associated rules, are, of course, implementation defined. For example, the implementation defines whether a given implementation-defined attribute can be used in a static expression.
{8652/0015} {AI95-00093-01} Implementations are allowed to support the Small attribute for floating types, as this was defined in Ada 83, even though the name would conflict with a language-defined attribute. 
4  Attributes are defined throughout this International Standard, and are summarized in K.2.
5  {AI95-00235} In general, the name in a prefix of an attribute_reference (or a range_attribute_reference) has to be resolved without using any context. However, in the case of the Access attribute, the expected type for the attribute_reference prefix prefix has to be a single access type, and if it is an access-to-subprogram type (see 3.10.2) then the resolution of the name can use the fact that the type of the object or the profile of the callable entity denoted by the prefix has to match the designated type or be type conformant with the designated profile of the access type.
Proof: {AI95-00235} In the general case, there is no “expected type” for the prefix of an attribute_reference. In the special case of 'Access, there is an “expected type” or “expected profile” for the prefix.
Reason: 'Access is a special case, because without it, it would be very difficult to take 'Access of an overloaded subprogram. 


Examples of attributes:
Color'First        -- minimum value of the enumeration type Color    (see 3.5.1)
Rainbow'Base'First -- same as Color'First                            (see 3.5.1)
Real'Digits        -- precision of the type Real                     (see 3.5.7)
Board'Last(2)      -- upper bound of the second dimension of Board   (see 3.6.1)
Board'Range(1)     -- index range of the first dimension of Board    (see 3.6.1)
Pool(K)'Terminated -- True if task Pool(K) is terminated             (see 9.1)
Date'Size          -- number of bits for records of type Date        (see 3.8)
Message'Address    -- address of the record variable Message         (see 3.7.1)

Extensions to Ada 83

We now uniformly treat X'Range as X'First..X'Last, allowing its use with scalar subtypes.
We allow any integer type in the static_expression of an attribute designator, not just a value of universal_integer. The preference rules ensure upward compatibility. 

Wording Changes from Ada 83

We use the syntactic category attribute_reference rather than simply "attribute" to avoid confusing the name of something with the thing itself.
The syntax rule for attribute_reference now uses identifier instead of simple_name, because attribute identifiers are not required to follow the normal visibility rules.
We now separate attribute_reference from range_attribute_reference, and enumerate the reserved words that are legal attribute or range attribute designators. We do this because identifier no longer includes reserved words.
The Ada 95 name resolution rules are a bit more explicit than in Ada 83. The Ada 83 rule said that the "meaning of the prefix of an attribute must be determinable independently of the attribute designator and independently of the fact that it is the prefix of an attribute." That isn't quite right since the meaning even in Ada 83 embodies whether or not the prefix is interpreted as a parameterless function call, and in Ada 95, it also embodies whether or not the prefix is interpreted as an implicit_dereference. So the attribute designator does make a difference — just not much.
Note however that if the attribute designator is Access, it makes a big difference in the interpretation of the prefix (see 3.10.2). 

Wording Changes from Ada 95

{8652/0015} {AI95-00093-01} Corrigendum: The wording was changed to allow implementations to continue to implement the Ada 83 Small attribute. This was always intended to be allowed.
{AI95-00235-01} The note about resolving prefixes of attributes was updated to reflect that the prefix of an Access attribute now has an expected type (see 3.10.2). 

Wording Changes from Ada 2005

{AI05-0006-1} Correction: Defined the nominal subtype of an attribute_reference to close a minor language hole. 

Contents   Index   References   Search   Previous   Next 
Ada-Europe Ada 2005 and 2012 Editions sponsored in part by Ada-Europe