# 3.5 Scalar Types

This Reference Manual output has not been verified, and may contain omissions or errors. Report any problems on the tracking issue

*Scalar* types comprise enumeration types, integer types, and real types. Enumeration types and integer types are called *discrete* types; each value of a discrete type has a *position number* which is an integer value. Integer types and real types are called *numeric* types. [All scalar types are ordered, that is, all relational operators are predefined for their values.]

#### Syntax

2`range_constraint`

` ::= `

**range**`range`

3
`range`

` ::= `

`range_attribute_reference`

| `simple_expression`

.. `simple_expression`

These need to be `simple_expression`

s rather than more general `expression`

s because ranges appear in membership tests and other contexts where `expression`

.. `expression`

would be ambiguous.

A *range* has a *lower bound* and an *upper bound* and specifies a subset of the values of some scalar type (the *type of the range*). A range with lower bound L and upper bound R is described by “L .. R”. If R is less than L, then the range is a *null range*, and specifies an empty set of values. Otherwise, the range specifies the values of the type from the lower bound to the upper bound, inclusive. A value *belongs* to a range if it is of the type of the range, and is in the subset of values specified by the range. A value *satisfies* a range constraint if it belongs to the associated range. One range is *included* in another if all values that belong to the first range also belong to the second.

#### Name Resolution Rules

5For a `subtype_indication`

containing a `range_constraint`

, either directly or as part of some other `scalar_constraint`

, the type of the `range`

shall resolve to that of the type determined by the `subtype_mark`

of the `subtype_indication`

. For a `range`

of a given type, the `simple_expression`

s of the `range`

(likewise, the `simple_expression`

s of the equivalent `range`

for a `range_attribute_reference`

) are expected to be of the type of the `range`

.

In Ada 95, `constraint`

s only appear within `subtype_indication`

s; things that look like constraints that appear in type declarations are called something else like `real_range_specification`

s.

We say "the expected type is ..." or "the type is expected to be ..." depending on which reads better. They are fundamentally equivalent, and both feed into the type resolution rules of 8.6.

In some cases, it doesn't work to use expected types. For example, in the above rule, we say that the “type of the `range`

shall resolve to ...” rather than “the expected type for the `range`

is ...” We then use “expected type” for the bounds. If we used “expected” at both points, there would be an ambiguity, since one could apply the rules of 8.6 either on determining the type of the range, or on determining the types of the individual bounds. It is clearly important to allow one bound to be of a universal type, and the other of a specific type, so we need to use “expected type” for the bounds. Hence, we used “shall resolve to” for the type of the range as a whole. There are other situations where “expected type” is not quite right, and we use “shall resolve to” instead.

#### Static Semantics

6The *base range* of a scalar type is the range of finite values of the type that can be represented in every unconstrained object of the type; it is also the range supported at a minimum for intermediate values during the evaluation of expressions involving predefined operators of the type.

Note that in some machine architectures intermediates in an expression (particularly if static), and register-resident variables might accommodate a wider range. The base range does not include the values of this wider range that are not assignable without overflow to memory-resident objects.

The base range of an enumeration type is the range of values of the enumeration type.

If the representation supports infinities, the base range is nevertheless restricted to include only the representable finite values, so that 'Base'First and 'Base'Last are always guaranteed to be finite.

**To be honest: **By a "value that can be assigned without overflow" we don't mean to restrict ourselves to values that can be represented exactly. Values between machine representable values can be assigned, but on subsequent reading, a slightly different value might be retrieved, as (partially) determined by the number of digits of precision of the type.

[A constrained scalar subtype is one to which a range constraint applies.] The *range* of a constrained scalar subtype is the range associated with the range constraint of the subtype. The *range* of an unconstrained scalar subtype is the base range of its type.

#### Dynamic Semantics

8A range is *compatible* with a scalar subtype if and only if it is either a null range or each bound of the range belongs to the range of the subtype. A `range_constraint`

is *compatible* with a scalar subtype if and only if its range is compatible with the subtype.

Only `range_constraint`

s (explicit or implicit) impose conditions on the values of a scalar subtype. The other `scalar_constraint`

s, `digits_constraint`

s and `delta_constraint`

s impose conditions on the subtype denoted by the `subtype_mark`

in a `subtype_indication`

, but don't impose a condition on the values of the subtype being defined. Therefore, a scalar subtype is not called *constrained* if all that applies to it is a `digits_constraint`

. Decimal subtypes are subtle, because a `digits_constraint`

without a `range_constraint`

nevertheless includes an implicit `range_constraint`

.

The elaboration of a `range_constraint`

consists of the evaluation of the `range`

. The evaluation of a `range`

determines a lower bound and an upper bound. If `simple_expression`

s are given to specify bounds, the evaluation of the `range`

evaluates these `simple_expression`

s in an arbitrary order, and converts them to the type of the `range`

. If a `range_attribute_reference`

is given, the evaluation of the `range`

consists of the evaluation of the `range_attribute_reference`

.

*Attributes*

For every scalar subtype S, the following attributes are defined:

S'First

- S'First denotes the lower bound of the range of S. The value of this attribute is of the type of S.

Evaluating S'First never raises Constraint_Error.

S'Last

- S'Last denotes the upper bound of the range of S. The value of this attribute is of the type of S.

Evaluating S'Last never raises Constraint_Error.

S'Range

- S'Range is equivalent to the
`range`

S'First .. S'Last. 15

S'Base- S'Base denotes an unconstrained subtype of the type of S. This unconstrained subtype is called the
*base subtype*of the type. 16

S'Min- S'Min denotes a function with the following specification:

function S'Min(Left, Right : S'Base)
return S'Base

18
- The function returns the lesser of the values of the two parameters.

The formal parameter names are italicized because they cannot be used in calls — see 6.4. Such a specification cannot be written by the user because an `attribute_reference`

is not permitted as the designator of a user-defined function, nor can its formal parameters be anonymous.

S'Max

- S'Max denotes a function with the following specification:

function S'Max(Left, Right : S'Base)
return S'Base

21
- The function returns the greater of the values of the two parameters.

S'Succ- S'Succ denotes a function with the following specification:

function S'Succ(Arg : S'Base)
return S'Base

24
- For an enumeration type, the function returns the value whose position number is one more than that of the value of
*Arg*; Constraint_Error is raised if there is no such value of the type. For an integer type, the function returns the result of adding one to the value of*Arg*. For a fixed point type, the function returns the result of adding*small*to the value of*Arg*. For a floating point type, the function returns the machine number (as defined in 3.5.7) immediately above the value of*Arg*; Constraint_Error is raised if there is no such machine number.

S'Succ for a modular integer subtype wraps around if the value of *Arg* is S'Base'Last. S'Succ for a signed integer subtype might raise Constraint_Error if the value of *Arg* is S'Base'Last, or it might return the out-of-base-range value S'Base'Last+1, as is permitted for all predefined numeric operations.

S'Pred

- S'Pred denotes a function with the following specification:

function S'Pred(Arg : S'Base)
return S'Base

27
- For an enumeration type, the function returns the value whose position number is one less than that of the value of
*Arg*; Constraint_Error is raised if there is no such value of the type. For an integer type, the function returns the result of subtracting one from the value of*Arg*. For a fixed point type, the function returns the result of subtracting*small*from the value of*Arg*. For a floating point type, the function returns the machine number (as defined in 3.5.7) immediately below the value of*Arg*; Constraint_Error is raised if there is no such machine number.

S'Pred for a modular integer subtype wraps around if the value of *Arg* is S'Base'First. S'Pred for a signed integer subtype might raise Constraint_Error if the value of *Arg* is S'Base'First, or it might return the out-of-base-range value S'Base'First–1, as is permitted for all predefined numeric operations.

*Paragraphs 28 through 37 were moved to 4.10, “Image Attributes”.*37.1/5

S'Wide_Wide_Width- S'Wide_Wide_Width denotes the maximum length of a Wide_Wide_String returned by S'Wide_Wide_Image over all values of the subtype S, assuming a default implementation of S'Put_Image. It denotes zero for a subtype that has a null range. Its type is
*universal_integer*. 38/5

S'Wide_Width- S'Wide_Width denotes the maximum length of a Wide_String returned by S'Wide_Image over all values of the subtype S, assuming a default implementation of S'Put_Image. It denotes zero for a subtype that has a null range. Its type is
*universal_integer*. 39/5

S'Width- S'Width denotes the maximum length of a String returned by S'Image over all values of the subtype S, assuming a default implementation of S'Put_Image. It denotes zero for a subtype that has a null range. Its type is
*universal_integer*. 39.1/2

S'Wide_Wide_Value- S'Wide_Wide_Value denotes a function with the following specification:

function S'Wide_Wide_Value(Arg : Wide_Wide_String)
return S'Base

39.3/2
- This function returns a value given an image of the value as a Wide_Wide_String, ignoring any leading or trailing spaces.
- For the evaluation of a call on S'Wide_Wide_Value for an enumeration subtype S, if the sequence of characters of the parameter (ignoring leading and trailing spaces) has the syntax of an enumeration literal and if it corresponds to a literal of the type of S (or corresponds to the result of S'Wide_Wide_Image for a nongraphic character of the type), the result is the corresponding enumeration value; otherwise, Constraint_Error is raised.

It's not crystal clear that Range_Check is appropriate here, but it doesn't seem worthwhile to invent a whole new check name just for this weird case, so we decided to lump it in with Range_Check.

**To be honest: **{*8652/0096*} A sequence of characters corresponds to the result of S'Wide_Wide_Image if it is the same ignoring case. Thus, the case of an image of a nongraphic character does not matter. For example, Character'Wide_Wide_Value("nul") does not raise Constraint_Error, even though Character'Wide_Wide_Image returns "NUL" for the nul character.

- For the evaluation of a call on S'Wide_Wide_Value for an integer subtype S, if the sequence of characters of the parameter (ignoring leading and trailing spaces) has the syntax of an integer literal, with an optional leading sign character (plus or minus for a signed type; only plus for a modular type), and the corresponding numeric value belongs to the base range of the type of S, then that value is the result; otherwise, Constraint_Error is raised.

We considered allowing 'Value to return a representable but out-of-range value without a Constraint_Error. However, we currently require (see 4.9) in an `assignment_statement`

like "X := <numeric_literal>;" that the value of the numeric-literal be in X's base range (at compile time), so it seems unfriendly and confusing to have a different range allowed for 'Value. Furthermore, for modular types, without the requirement for being in the base range, 'Value would have to handle arbitrarily long literals (since overflow never occurs for modular types).

- For the evaluation of a call on S'Wide_Wide_Value for a real subtype S, if the sequence of characters of the parameter (ignoring leading and trailing spaces) has the syntax of one of the following:

`numeric_literal`

39.8/2`numeral`

.[`exponent`

] 39.9/2- .
`numeral`

[`exponent`

] 39.10/2 `base`

#`based_numeral`

.#[`exponent`

] 39.11/2`base`

#.`based_numeral`

#[`exponent`

]

- with an optional leading sign character (plus or minus), and if the corresponding numeric value belongs to the base range of the type of S, then that value is the result; otherwise, Constraint_Error is raised. The sign of a zero value is preserved (positive if none has been specified) if S'Signed_Zeros is True.

S'Wide_Value- S'Wide_Value denotes a function with the following specification:

function S'Wide_Value(Arg : Wide_String)
return S'Base

42
- This function returns a value given an image of the value as a Wide_String, ignoring any leading or trailing spaces.
- For the evaluation of a call on S'Wide_Value for an enumeration subtype S, if the sequence of characters of the parameter (ignoring leading and trailing spaces) has the syntax of an enumeration literal and if it corresponds to a literal of the type of S (or corresponds to the result of S'Wide_Image for a value of the type, assuming a default implementation of S'Put_Image), the result is the corresponding enumeration value; otherwise, Constraint_Error is raised. For a numeric subtype S, the evaluation of a call on S'Wide_Value with
*Arg*of type Wide_String is equivalent to a call on S'Wide_Wide_Value for a corresponding*Arg*of type Wide_Wide_String.

*This paragraph was deleted.*

S'Wide_Value is subtly different from S'Wide_Wide_Value for enumeration subtypes since S'Wide_Image might produce a different sequence of characters than S'Wide_Wide_Image if the enumeration literal uses characters outside of the predefined type Wide_Character. That is why we don't just define S'Wide_Value in terms of S'Wide_Wide_Value for enumeration subtypes. S'Wide_Value and S'Wide_Wide_Value for numeric subtypes yield the same result given the same sequence of characters.

*Paragraphs 44 through 51 were moved to Wide_Wide_Value.*52

S'Value- S'Value denotes a function with the following specification:

function S'Value(Arg : String)
return S'Base

54
- This function returns a value given an image of the value as a String, ignoring any leading or trailing spaces.
- For the evaluation of a call on S'Value for an enumeration subtype S, if the sequence of characters of the parameter (ignoring leading and trailing spaces) has the syntax of an enumeration literal and if it corresponds to a literal of the type of S (or corresponds to the result of S'Image for a value of the type, assuming a default implementation of S'Put_Image), the result is the corresponding enumeration value; otherwise, Constraint_Error is raised. For a numeric subtype S, the evaluation of a call on S'Value with
*Arg*of type String is equivalent to a call on S'Wide_Wide_Value for a corresponding*Arg*of type Wide_Wide_String.

S'Value is subtly different from S'Wide_Wide_Value for enumeration subtypes; see the discussion under S'Wide_Value.

#### Implementation Permissions

56/2An implementation may extend the Wide_Wide_Value, [Wide_Value, Value, Wide_Wide_Image, Wide_Image, and Image] attributes of a floating point type to support special values such as infinities and NaNs.

The permission is really only necessary for Wide_Wide_Value, because Value and Wide_Value are defined in terms of Wide_Wide_Value, and because the behavior of Wide_Wide_Image, Wide_Image, and Image is already unspecified for things like infinities and NaNs.

This is to allow implementations to define full support for IEEE arithmetic. See also the similar permission for Get in A.10.9.

An implementation may extend the Wide_Wide_Value, Wide_Value, and Value attributes of a character type to accept strings of the form “Hex_*hhhhhhhh*” (ignoring case) for any character (not just the ones for which Wide_Wide_Image would produce that form — see 3.5.2), as well as three-character strings of the form “'*X*'”, where *X* is any character, including nongraphic characters.

#### Static Semantics

56.2/3For a scalar type, the following language-defined representation aspect may be specified with an `aspect_specification`

(see 13.1.1):

Default_Value

- This aspect shall be specified by a static expression, and that expression shall be explicit, even if the aspect has a boolean type. Default_Value shall be specified only on a
`full_type_declaration`

.

The part about requiring an explicit expression is to disallow omitting the value for this aspect, which would otherwise be allowed by the rules of 13.1.1.

This is a representation aspect in order to disallow specifying it on a derived type that has inherited primitive subprograms; that is necessary as the sizes of **out** parameters could be different whether or not a Default_Value is specified (see 6.4.1).

**Aspect Description for ****Default_Value: **Default value for a scalar subtype.

If a derived type inherits a boolean Default_Value aspect, the aspect may be specified to have any value for the derived type. If a derived type *T* does not inherit a Default_Value aspect, it shall not specify such an aspect if it inherits a primitive subprogram that has a parameter of type *T* of mode **out**.

This overrides the 13.1.1 rule that says that a boolean aspect with a value True cannot be changed.

The second sentence is to avoid violating the rules specified in 6.4.1 about view conversions of **out** parameters with a specified Default_Value aspect.

#### Name Resolution Rules

56.5/3The expected type for the `expression`

specified for the Default_Value aspect is the type defined by the `full_type_declaration`

on which it appears.

NOTE 1 The evaluation of S'First or S'Last never raises an exception. If a scalar subtype S has a nonnull range, S'First and S'Last belong to this range. These values can, for example, always be assigned to a variable of subtype S.

This paragraph addresses an issue that came up with Ada 83, where for fixed point types, the end points of the range specified in the type definition were not necessarily within the base range of the type. However, it was later clarified (and we reconfirm it in 3.5.9, “Fixed Point Types”) that the First and Last attributes reflect the true bounds chosen for the type, not the bounds specified in the type definition (which might be outside the ultimately chosen base range).

NOTE 2 For a subtype of a scalar type, the result delivered by the attributes Succ, Pred, and Value can be outside to the subtype; similarly, the actual parameters of the attributes Succ, Pred, and Image can also be outside the subtype.

NOTE 3 For any value V (including any nongraphic character) of an enumeration subtype S without a specified Put_Image (see 4.10), S'Value(S'Image(V)) equals V, as do S'Wide_Value(S'Wide_Image(V)) and S'Wide_Wide_Value(S'Wide_Wide_Image(V)). None of these expressions ever raise Constraint_Error.

#### Examples

60*Examples of ranges:*

-10 .. 10
X .. X + 1
0.0 .. 2.0*Pi
Red .. Green -- see 3.5.1
1 .. 0 -- a null range
Table'Range -- a range attribute reference (see 3.6)

62
*Examples of range constraints:*

range -999.0 .. +999.0
range S'First+1 .. S'Last-1

#### Incompatibilities With Ada 83

S'Base is no longer defined for nonscalar types. One conceivable existing use of S'Base for nonscalar types is S'Base'Size where S is a generic formal private type. However, that is not generally useful because the actual subtype corresponding to S might be a constrained array or discriminated type, which would mean that S'Base'Size might very well overflow (for example, S'Base'Size where S is a constrained subtype of String will generally be 8 * (Integer'Last + 1)). For derived discriminated types that are packed, S'Base'Size might not even be well defined if the first subtype is constrained, thereby allowing some amount of normally required “dope” to have been squeezed out in the packing. Hence our conclusion is that S'Base'Size is not generally useful in a generic, and does not justify keeping the attribute Base for nonscalar types just so it can be used as a `prefix`

.

#### Extensions to Ada 83

The attribute S'Base for a scalar subtype is now permitted anywhere a `subtype_mark`

is permitted. S'Base'First .. S'Base'Last is the base range of the type. Using an `attribute_definition_clause`

, one cannot specify any subtype-specific attributes for the subtype denoted by S'Base (the base subtype).

The attribute S'Range is now allowed for scalar subtypes.

The attributes S'Min and S'Max are now defined, and made available for all scalar types.

The attributes S'Succ, S'Pred, S'Image, S'Value, and S'Width are now defined for real types as well as discrete types.

Wide_String versions of S'Image and S'Value are defined. These are called S'Wide_Image and S'Wide_Value to avoid introducing ambiguities involving uses of these attributes with string literals.

#### Wording Changes from Ada 83

We now use the syntactic category `range_attribute_reference`

since it is now syntactically distinguished from other attribute references.

The definition of S'Base has been moved here from 3.3.3 since it now applies only to scalar types.

More explicit rules are provided for nongraphic characters.

#### Extensions to Ada 95

The attributes Wide_Wide_Image, Wide_Wide_Value, and Wide_Wide_Width are new. Note that Wide_Image and Wide_Value are now defined in terms of Wide_Wide_Image and Wide_Wide_Value, but the image of types other than characters have not changed.

#### Wording Changes from Ada 95

The Wide_Image and Wide_Value attributes are now defined in terms of Wide_Wide_Image and Wide_Wide_Value, but the images of numeric types have not changed.

#### Inconsistencies With Ada 2005

Soft hyphen (code point 173) is nongraphic in ISO/IEC 10646:2011 (and also in the 2003 version of that standard). Thus, we have given it the language-defined name *soft_hyphen*. This changes the result of Character'Image (and all of the related types and Image attributes) for this character, and changes the behavior of Character'Value (and all of the related types and Value attributes) for this character, and (in unusual circumstances), changes the result for Character'Width (and all of the related types and Width attributes). The vast majority of programs won't see any difference, as they are already prepared to handle nongraphic characters.

Added an Implementation Permissions to let Wide_Wide_Value, Wide_Value, and Value accept strings in the form of literals containing nongraphic characters and "Hex_hhhhhhhh" for Latin-1 and graphic characters. These were required to raise Constraint_Error in Ada 2005. Since these attributes aren't very useful, implementations were inconsistent as to whether these were accepted, and since code that would care why the attribute failed seems unlikely, this should not be a problem in practice.

#### Extensions to Ada 2005

The new aspect Default_Value allows defining implicit initial values (see 3.3.1) for scalar types.

#### Extensions to Ada 2012

**Corrigendum:** An object can be now used as the prefix of the Image attribute (as well as Wide_Image and Wide_Wide_Image), a convenience feature already present in some implementations.

## 3.5.1 Enumeration Types

1[ An `enumeration_type_definition`

defines an enumeration type.]

#### Syntax

2`enumeration_type_definition`

` ::= `

(`enumeration_literal_specification`

{, `enumeration_literal_specification`

})

3
`enumeration_literal_specification`

` ::= `

`defining_identifier`

| `defining_character_literal`

4
`defining_character_literal`

` ::= `

`character_literal`

#### Legality Rules

5/3The `defining_identifier`

s in upper case [and the `defining_character_literal`

s] listed in an `enumeration_type_definition`

shall be distinct.

For character literals, this is a ramification of the normal disallowance of homographs explicitly declared immediately in the same declarative region.

To ease implementation of the attribute Wide_Wide_Value, we require that all enumeration literals have distinct images.

#### Static Semantics

6/3Each `enumeration_literal_specification`

is the explicit declaration of the corresponding *enumeration literal*: it declares a parameterless function, whose defining name is the `defining_identifier`

or `defining_character_literal`

, and whose result subtype is the base subtype of the enumeration type.

This rule defines the profile of the enumeration literal, which is used in the various types of conformance.

The parameterless function associated with an enumeration literal is fully defined by the `enumeration_type_definition`

; a body is not permitted for it, and it never fails the Elaboration_Check when called.

The result subtype is primarily a concern when an enumeration literal is used as the `expression`

of a case statement, due to the full coverage requirement based on the nominal subtype.

Each enumeration literal corresponds to a distinct value of the enumeration type, and to a distinct position number. The position number of the value of the first listed enumeration literal is zero; the position number of the value of each subsequent enumeration literal is one more than that of its predecessor in the list.

[The predefined order relations between values of the enumeration type follow the order of corresponding position numbers.]

[ If the same `defining_identifier`

or `defining_character_literal`

is specified in more than one `enumeration_type_definition`

, the corresponding enumeration literals are said to be *overloaded*. At any place where an overloaded enumeration literal occurs in the text of a program, the type of the enumeration literal has to be determinable from the context (see 8.6).]

#### Dynamic Semantics

10The elaboration of an `enumeration_type_definition`

creates the enumeration type and its first subtype, which is constrained to the base range of the type.

The first subtype of a discrete type is always constrained, except in the case of a derived type whose parent subtype is Whatever'Base.

When called, the parameterless function associated with an enumeration literal returns the corresponding value of the enumeration type.

NOTE If an enumeration literal occurs in a context that does not otherwise suffice to determine the type of the literal, then qualification by the name of the enumeration type is one way to resolve the ambiguity (see 4.7).

#### Examples

13*Examples of enumeration types and subtypes:*

type Day is (Mon, Tue, Wed, Thu, Fri, Sat, Sun);
type Month_Name is (January, February, March, April, May, June, July,
August, September, October, November, December);
type Suit is (Clubs, Diamonds, Hearts, Spades);
type Gender is (M, F);
type Level is (Low, Medium, Urgent);
type Color is (White, Red, Yellow, Green, Blue, Brown, Black);
type Light is (Red, Amber, Green); -- Red and Green are overloaded
15
type Hexa is ('A', 'B', 'C', 'D', 'E', 'F');
type Mixed is ('A', 'B', '*', B, None, '?', '%');
16
subtype Weekday is Day range Mon .. Fri;
subtype Major is Suit range Hearts .. Spades;
subtype Rainbow is Color range Red .. Blue;
-- the Color Red, not the Light

#### Wording Changes from Ada 83

The syntax rule for `defining_character_literal`

is new. It is used for the defining occurrence of a `character_literal`

, analogously to `defining_identifier`

. Usage occurrences use the `name`

or `selector_name`

syntactic categories.

We emphasize the fact that an enumeration literal denotes a function, which is called to produce a value.

#### Incompatibilities With Ada 2005

Required that all enumeration literals in a type have distinct images; this might not be the case since upper case conversion can map distinct characters to the same upper case character. This can only happen for identifiers using Unicode characters first allowed by Ada 2005; moreover, the original definition of Ada 2005 was confused and appeared to require inconsistent results from the Image attribute, so implementations that allowed problematic cases are rare; the problematic cases are very rare; so it is expected that this change would only affect test programs.

#### Wording Changes from Ada 2005

Defined the result subtype of an enumeration literal to close a minor language hole.

## 3.5.2 Character Types

#### Static Semantics

1An enumeration type is said to be a *character type* if at least one of its enumeration literals is a `character_literal`

.

The predefined type Character is a character type whose values correspond to the 256 code points of Row 00 (also known as Latin-1) of the ISO/IEC 10646:2020 Basic Multilingual Plane (BMP). Each of the graphic characters of Row 00 of the BMP has a corresponding `character_literal`

in Character. Each of the nongraphic characters of Row 00 has a corresponding language-defined name, which is not usable as an enumeration literal, but which is usable with the attributes Image, Wide_Image, Wide_Wide_Image, Value, Wide_Value, and Wide_Wide_Value; these names are given in the definition of type Character in A.1, “The Package Standard”, but are set in *italics*.

The predefined type Wide_Character is a character type whose values correspond to the 65536 code points of the ISO/IEC 10646:2020 Basic Multilingual Plane (BMP). Each of the graphic characters of the BMP has a corresponding `character_literal`

in Wide_Character. The first 256 values of Wide_Character have the same `character_literal`

or language-defined name as defined for Character. Each of the `graphic_character`

s has a corresponding `character_literal`

.

The predefined type Wide_Wide_Character is a character type whose values correspond to the 2147483648 code points of the ISO/IEC 10646:2020 character set. Each of the `graphic_character`

s has a corresponding `character_literal`

in Wide_Wide_Character. The first 65536 values of Wide_Wide_Character have the same `character_literal`

or language-defined name as defined for Wide_Character.

The characters whose code point is larger than 16#FF# and which are not `graphic_character`

s have language-defined names which are formed by appending to the string "Hex_" the representation of their code point in hexadecimal as eight extended digits. As with other language-defined names, these names are usable only with the attributes (Wide_)Wide_Image and (Wide_)Wide_Value; they are not usable as enumeration literals.

The language-defined names are not usable as enumeration literals to avoid "polluting" the name space. Since Wide_Character and Wide_Wide_Character are defined in Standard, if the language-defined names were usable as enumeration literals, they would hide other nonoverloadable declarations with the same names in **use**-d packages.

*Original Paragraphs 4 and 5 were deleted.*

NOTE 1 The language-defined library package Characters.Latin_1 (see A.3.3) includes the declaration of constants denoting control characters, lower case characters, and special characters of the predefined type Character.

**To be honest: **The package ASCII does the same, but only for the first 128 characters of Character. Hence, it is an obsolescent package, and we no longer mention it here.

NOTE 2 A conventional character set such as *EBCDIC* can be declared as a character type; the internal codes of the characters can be specified by an `enumeration_representation_clause`

as explained in 13.4.

#### Examples

10*Example of a character type: *

type Roman_Digit is ('I', 'V', 'X', 'L', 'C', 'D', 'M');

#### Inconsistencies With Ada 83

The declaration of Wide_Character in package Standard hides use-visible declarations with the same defining identifier. In the unlikely event that an Ada 83 program had depended on such a use-visible declaration, and the program remains legal after the substitution of Standard.Wide_Character, the meaning of the program will be different.

#### Incompatibilities With Ada 83

The presence of Wide_Character in package Standard means that an expression such as

'a' = 'b'

is ambiguous in Ada 95, whereas in Ada 83 both literals could be resolved to be of type Character.

The change in visibility rules (see 4.2) for character literals means that additional qualification might be necessary to resolve expressions involving overloaded subprograms and character literals.

#### Extensions to Ada 83

The type Character has been extended to have 256 positions, and the type Wide_Character has been added. Note that this change was already approved by the ARG for Ada 83 conforming compilers.

The rules for referencing character literals are changed (see 4.2), so that the declaration of the character type need not be directly visible to use its literals, similar to **null** and string literals. Context is used to resolve their type.

#### Inconsistencies With Ada 95

Ada 95 defined most characters in Wide_Character to be graphic characters, while Ada 2005 uses the categorizations from ISO-10646:2003. It also provides language-defined names for all nongraphic characters. That means that in Ada 2005, Wide_Character'Wide_Value will raise Constraint_Error for a string representing a `character_literal`

of a nongraphic character, while Ada 95 would have accepted it. Similarly, the result of Wide_Character'Wide_Image will change for such nongraphic characters.

The language-defined names FFFE and FFFF were replaced by a consistent set of language-defined names for all nongraphic characters with code points greater than 16#FF#. That means that in Ada 2005, Wide_Character'Wide_Value("FFFE") will raise Constraint_Error while Ada 95 would have accepted it. Similarly, the result of Wide_Character'Wide_Image will change for the position numbers 16#FFFE# and 16#FFFF#. It is very unlikely that this will matter in practice, as these names do not represent usable characters.

Because of the previously mentioned changes to the Wide_Character'Wide_Image of various character values, the value of attribute Wide_Width will change for some subtypes of Wide_Character. However, the new language-defined names were chosen so that the value of Wide_Character'Wide_Width itself does not change.

The declaration of Wide_Wide_Character in package Standard hides use-visible declarations with the same defining identifier. In the (very) unlikely event that an Ada 95 program had depended on such a use-visible declaration, and the program remains legal after the substitution of Standard.Wide_Wide_Character, the meaning of the program will be different.

#### Extensions to Ada 95

#### Wording Changes from Ada 95

We dropped the for nonstandard interpretation of character sets; an implementation can do what it wants in a nonstandard mode, so there isn't much point to any advice.

#### Wording Changes from Ada 2005

Removed the position numbers of nongraphic characters from the text, as it is wrong and thus misleading.

Changed "code position" to "code point" consistently throughout the standard, as ISO/IEC 10646:2011 prefers "code point" and we are referring to the definition in that Standard. This change also reduces confusion between "code point" and "position number"; while these have the same values for the predefined character types, there is no required relationship for other character types.

## 3.5.3 Boolean Types

#### Static Semantics

1There is a predefined enumeration type named Boolean, [declared in the visible part of package Standard]. It has the two enumeration literals False and True ordered with the relation False < True. Any descendant of the predefined type Boolean is called a *boolean* type.

An implementation is not required to support enumeration representation clauses on boolean types that impose an unacceptable implementation burden. See 13.4, “Enumeration Representation Clauses”. However, it is generally straightforward to support representations where False is zero and True is 2**n – 1 for some n.

## 3.5.4 Integer Types

1An `integer_type_definition`

defines an integer type; it defines either a *signed* integer type, or a *modular* integer type. The base range of a signed integer type includes at least the values of the specified range. A modular type is an integer type with all arithmetic modulo a specified positive *modulus*; such a type corresponds to an unsigned type with wrap-around semantics.

#### Syntax

2`integer_type_definition`

` ::= `

`signed_integer_type_definition`

| `modular_type_definition`

3
`signed_integer_type_definition`

` ::= `

**range** *static_*`simple_expression`

.. *static_*`simple_expression`

We don't call this a `range_constraint`

, because it is rather different — not only is it required to be static, but the associated overload resolution rules are different than for normal range constraints. A similar comment applies to `real_range_specification`

. This used to be `integer_range_specification`

but when we added support for modular types, it seemed overkill to have three levels of syntax rules, and just calling these `signed_integer_range_specification`

and `modular_range_specification`

loses the fact that they are defining different classes of types, which is important for the generic type matching rules.

`modular_type_definition`

` ::= `

**mod***static_*`expression`

#### Name Resolution Rules

5/5Each `simple_expression`

in a `signed_integer_type_definition`

is expected to be of any integer type; they can be of different integer types. The `expression`

in a `modular_type_definition`

is likewise expected to be of any integer type.

#### Legality Rules

6The `simple_expression`

s of a `signed_integer_type_definition`

shall be static, and their values shall be in the range System.Min_Int .. System.Max_Int.

The `expression`

of a `modular_type_definition`

shall be static, and its value (the *modulus*) shall be positive, and shall be no greater than System.Max_Binary_Modulus if a power of 2, or no greater than System.Max_Nonbinary_Modulus if not.

For a 2's-complement machine, supporting nonbinary moduli greater than System.Max_Int can be quite difficult, whereas essentially any binary moduli are straightforward to support, up to 2*System.Max_Int+2, so this justifies having two separate limits.

#### Static Semantics

8The set of values for a signed integer type is the (infinite) set of mathematical integers[, though only values of the base range of the type are fully supported for run-time operations]. The set of values for a modular integer type are the values from 0 to one less than the modulus, inclusive.

A `signed_integer_type_definition`

defines an integer type whose base range includes at least the values of the `simple_expression`

s and is symmetric about zero, excepting possibly an extra negative value. A `signed_integer_type_definition`

also defines a constrained first subtype of the type, with a range whose bounds are given by the values of the `simple_expression`

s, converted to the type being defined.

The base range of a signed integer type might be much larger than is necessary to satisfy the above requirements.

**To be honest: **The conversion mentioned above is not an *implicit subtype conversion* (which is something that happens at overload resolution, see 4.6), although it happens implicitly. Therefore, the freezing rules are not invoked on the type (which is important so that representation items can be given for the type).

A `modular_type_definition`

defines a modular type whose base range is from zero to one less than the given modulus. A `modular_type_definition`

also defines a constrained first subtype of the type with a range that is the same as the base range of the type.

There is a predefined signed integer subtype named Integer[, declared in the visible part of package Standard]. It is constrained to the base range of its type.

Integer is a constrained subtype, rather than an unconstrained subtype. This means that on assignment to an object of subtype Integer, a range check is required. On the other hand, an object of subtype Integer'Base is unconstrained, and no range check (only overflow check) is required on assignment. For example, if the object is held in an extended-length register, its value might be outside of Integer'First .. Integer'Last. All parameter and result subtypes of the predefined integer operators are of such unconstrained subtypes, allowing extended-length registers to be used as operands or for the result. In an earlier version of Ada 95, Integer was unconstrained. However, the fact that certain Constraint_Errors might be omitted or appear elsewhere was felt to be an undesirable upward inconsistency in this case. Note that for Float, the opposite conclusion was reached, partly because of the high cost of performing range checks when not actually necessary. Objects of subtype Float are unconstrained, and no range checks, only overflow checks, are performed for them.

Integer has two predefined subtypes, [declared in the visible part of package Standard:]

subtype Natural is Integer range 0 .. Integer'Last;
subtype Positive is Integer range 1 .. Integer'Last;

14
A type defined by an `integer_type_definition`

is implicitly derived from *root_integer*, an anonymous predefined (specific) integer type, whose base range is System.Min_Int .. System.Max_Int. However, the base range of the new type is not inherited from *root_integer*, but is instead determined by the range or modulus specified by the `integer_type_definition`

. [Integer literals are all of the type *universal_integer*, the universal type (see 3.4.1) for the class rooted at *root_integer*, allowing their use with the operations of any integer type.]

This implicit derivation is not considered exactly equivalent to explicit derivation via a `derived_type_definition`

. In particular, integer types defined via a `derived_type_definition`

inherit their base range from their parent type. A type defined by an `integer_type_definition`

does not necessarily inherit its base range from *root_integer*. It is not specified whether the implicit derivation from *root_integer* is direct or indirect, not that it really matters. All we want is for all integer types to be descendants of *root_integer*.

{*8652/0099*} Note that this derivation does not imply any inheritance of subprograms. Subprograms are inherited only for types derived by a `derived_type_definition`

(see 3.4), or a `private_extension_declaration`

(see 7.3, 7.3.1, and 12.5.1).

It is the intent that even nonstandard integer types (see below) will be descendants of *root_integer*, even though they might have a base range that exceeds that of *root_integer*. This causes no problem for static calculations, which are performed without range restrictions (see 4.9). However for run-time calculations, it is possible that Constraint_Error might be raised when using an operator of *root_integer* on the result of 'Val applied to a value of a nonstandard integer type.

The *position number* of an integer value is equal to the value.

For every modular subtype S, the following attributes are defined:

S'Mod

- S'Mod denotes a function with the following specification:

function S'Mod (Arg : universal_integer)
return S'Base

16.3/2
- This function returns
*Arg***mod**S'Modulus, as a value of the type of S. 17

S'Modulus- S'Modulus yields the modulus of the type of S, as a value of the type
*universal_integer*.

#### Dynamic Semantics

18The elaboration of an `integer_type_definition`

creates the integer type and its first subtype.

For a modular type, if the result of the execution of a predefined operator (see 4.5) is outside the base range of the type, the result is reduced modulo the modulus of the type to a value that is within the base range of the type.

For a signed integer type, the exception Constraint_Error is raised by the execution of an operation that cannot deliver the correct result because it is outside the base range of the type. [ For any integer type, Constraint_Error is raised by the operators "/", "**rem**", and "**mod**" if the right operand is zero.]

#### Implementation Requirements

21In an implementation, the range of Integer shall include the range –2**15+1 .. +2**15–1.

If Long_Integer is predefined for an implementation, then its range shall include the range –2**31+1 .. +2**31–1.

System.Max_Binary_Modulus shall be at least 2**16.

#### Implementation Permissions

24/5For the execution of a predefined operation of a signed integer type, it is optional to raise Constraint_Error if the result is outside the base range of the type, so long as the correct result is produced.

Constraint_Error is never raised for operations on modular types, except for divide-by-zero (and **rem**/**mod**-by-zero).

An implementation may provide additional predefined signed integer types[, declared in the visible part of Standard], whose first subtypes have names of the form Short_Integer, Long_Integer, Short_Short_Integer, Long_Long_Integer, etc. Different predefined integer types are allowed to have the same base range. However, the range of Integer should be no wider than that of Long_Integer. Similarly, the range of Short_Integer (if provided) should be no wider than Integer. Corresponding recommendations apply to any other predefined integer types. An implementation may support base ranges for which there is no corresponding named integer type. The range of each first subtype should be the base range of its type.

An implementation may provide *nonstandard integer types*, descendants of *root_integer* that are declared outside of the specification of package Standard, which may have different characteristics than a type defined by an `integer_type_definition`

. For example, a nonstandard integer type can have an asymmetric base range or it can be disallowed as an array or loop index (a very long integer). Any type descended from a nonstandard integer type is also nonstandard. An implementation may place arbitrary restrictions on the use of such types; it is implementation defined whether operators that are predefined for “any integer type” are defined for a particular nonstandard integer type. [In any case, such types are not permitted as `explicit_generic_actual_parameter`

s for formal scalar types — see 12.5.2.]

Any nonstandard integer types and the operators defined for them.

For a one's complement machine, the high bound of the base range of a modular type whose modulus is one less than a power of 2 may be equal to the modulus, rather than one less than the modulus. It is implementation defined for which powers of 2, if any, this permission is exercised.

{*8652/0003*} For a one's complement machine, implementations may support nonbinary modulus values greater than System.Max_Nonbinary_Modulus. It is implementation defined which specific values greater than System.Max_Nonbinary_Modulus, if any, are supported.

On a one's complement machine, the natural full word type would have a modulus of 2**Word_Size–1. However, we would want to allow the all-ones bit pattern (which represents negative zero as a number) in logical operations. These permissions are intended to allow that and the natural modulus value without burdening implementations with supporting expensive modulus values.

#### Implementation Advice

28An implementation should support Long_Integer in addition to Integer if the target machine supports 32-bit (or longer) arithmetic. No other named integer subtypes are recommended for package Standard. Instead, appropriate named integer subtypes should be provided in the library package Interfaces (see B.2).

Long_Integer should be declared in Standard if the target supports 32-bit arithmetic. No other named integer subtypes should be declared in Standard.

To promote portability, implementations should explicitly declare the integer (sub)types Integer and Long_Integer in Standard, and leave other predefined integer types anonymous. For implementations that already support Byte_Integer, etc., upward compatibility argues for keeping such declarations in Standard during the transition period, but perhaps generating a warning on use. A separate package Interfaces in the predefined environment is available for pre-declaring types such as Integer_8, Integer_16, etc. See B.2. In any case, if the user declares a subtype (first or not) whose range fits in, for example, a byte, the implementation can store variables of the subtype in a single byte, even if the base range of the type is wider.

An implementation for a two's complement machine should support modular types with a binary modulus up to System.Max_Int*2+2. An implementation should support a nonbinary modulus up to Integer'Last.

For a two's complement target, modular types with a binary modulus up to System.Max_Int*2+2 should be supported. A nonbinary modulus up to Integer'Last should be supported.

Modular types provide bit-wise "**and**", "**or**", "**xor**", and "**not**" operations. It is important for systems programming that these be available for all integer types of the target hardware.

Note that on a one's complement machine, the largest supported modular type would normally have a nonbinary modulus. On a two's complement machine, the largest supported modular type would normally have a binary modulus.

Supporting a nonbinary modulus greater than Integer'Last can impose an undesirable implementation burden on some machines.

NOTE 1 Integer literals are of the anonymous predefined integer type *universal_integer*. Other integer types have no literals. However, the overload resolution rules (see 8.6, “The Context of Overload Resolution”) allow expressions of the type *universal_integer* whenever an integer type is expected.

NOTE 2 The same arithmetic operators are predefined for all signed integer types defined by a `signed_integer_type_definition`

(see 4.5, “Operators and Expression Evaluation”). For modular types, these same operators are predefined, plus bit-wise logical operators (**and**, **or**, **xor**, and **not**). In addition, for the unsigned types declared in the language-defined package Interfaces (see B.2), functions are defined that provide bit-wise shifting and rotating.

NOTE 3 Modular types match a `generic_formal_parameter_declaration`

of the form "**type** T **is mod** <>;"; signed integer types match "**type** T **is range** <>;" (see 12.5.2).

#### Examples

33*Examples of integer types and subtypes: *

type Page_Num is range 1 .. 2_000;
type Line_Size is range 1 .. Max_Line_Size;
35
subtype Small_Int is Integer range -10 .. 10;
subtype Column_Ptr is Line_Size range 1 .. 10;
subtype Buffer_Size is Integer range 0 .. Max;
36
type Byte is mod 256; -- an unsigned byte
type Hash_Index is mod 97; -- modulus is prime

#### Extensions to Ada 83

An implementation is allowed to support any number of distinct base ranges for integer types, even if fewer integer types are explicitly declared in Standard.

Modular (unsigned, wrap-around) types are new.

#### Wording Changes from Ada 83

Ada 83's integer types are now called "signed" integer types, to contrast them with "modular" integer types.

Standard.Integer, Standard.Long_Integer, etc., denote constrained subtypes of predefined integer types, consistent with the Ada 95 model that only subtypes have names.

We now impose minimum requirements on the base range of Integer and Long_Integer.

We no longer explain integer type definition in terms of an equivalence to a normal type derivation, except to say that all integer types are by definition implicitly derived from *root_integer*. This is for various reasons.

First of all, the equivalence with a type derivation and a subtype declaration was not perfect, and was the source of various AIs (for example, is the conversion of the bounds static? Is a numeric type a derived type with respect to other rules of the language?)

Secondly, we don't want to require that every integer size supported shall have a corresponding named type in Standard. Adding named types to Standard creates nonportabilities.

Thirdly, we don't want the set of types that match a formal derived type "type T is new Integer;" to depend on the particular underlying integer representation chosen to implement a given user-defined integer type. Hence, we would have needed anonymous integer types as parent types for the implicit derivation anyway. We have simply chosen to identify only one anonymous integer type — *root_integer*, and stated that every integer type is derived from it.

Finally, the “fiction” that there were distinct preexisting predefined types for every supported representation breaks down for fixed point with arbitrary smalls, and was never exploited for enumeration types, array types, etc. Hence, there seems little benefit to pushing an explicit equivalence between integer type definition and normal type derivation.

#### Extensions to Ada 95

The Mod attribute is new. It eases mixing of signed and unsigned values in an expression, which can be difficult as there may be no type which can contain all of the values of both of the types involved.

#### Wording Changes from Ada 95

{*8652/0003*} **Corrigendum:** Added additional permissions for modular types on one's complement machines.

## 3.5.5 Operations of Discrete Types

#### Static Semantics

1For every discrete subtype S, the following attributes are defined:

S'Pos

- S'Pos denotes a function with the following specification:

function S'Pos(Arg : S'Base)
return universal_integer

4
- This function returns the position number of the value of
*Arg*, as a value of type*universal_integer*. 5

S'Val- S'Val denotes a function with the following specification:

function S'Val(Arg : universal_integer)
return S'Base

7
- This function returns a value of the type of S whose position number equals the value of
*Arg*. For the evaluation of a call on S'Val, if there is no value in the base range of its type with the given position number, Constraint_Error is raised.

By the overload resolution rules, a formal parameter of type *universal_integer* allows an actual parameter of any integer type.

We considered allowing S'Val for a signed integer subtype S to return an out-of-range value, but since checks were required for enumeration and modular types anyway, the allowance didn't seem worth the complexity of the rule.

For every static discrete subtype S for which there exists at least one value belonging to S that satisfies the predicates of S, the following attributes are defined:

S'First_Valid

- S'First_Valid denotes the smallest value that belongs to S and satisfies the predicates of S. The value of this attribute is of the type of S.

S'Last_Valid- S'Last_Valid denotes the largest value that belongs to S and satisfies the predicates of S. The value of this attribute is of the type of S.

[First_Valid and Last_Valid `attribute_reference`

s are always static expressions. Any explicit predicate of S can only have been specified by a Static_Predicate aspect.]

An `attribute_reference`

is static if the prefix is a static subtype (see 4.9), (true by definition) and any arguments are static (there are none). Similarly, a dynamic predicate always makes a subtype nonstatic. QED.

We require there to be at least one value so that these are always values of the subtype. (This sidesteps the question of what to return for a subtype with no values.)

These attributes are intended primarily for use in the case where the Static_Predicate aspect of S has been specified; First and Last are equivalent if these are allowed and there is no predicate.

#### Implementation Advice

8For the evaluation of a call on S'Pos for an enumeration subtype, if the value of the operand does not correspond to the internal code for any enumeration literal of its type [(perhaps due to an uninitialized variable)], then the implementation should raise Program_Error. This is particularly important for enumeration types with noncontiguous internal codes specified by an `enumeration_representation_clause`

.

Program_Error should be raised for the evaluation of S'Pos for an enumeration type, if the value of the operand does not correspond to the internal code for any enumeration literal of the type.

We say Program_Error here, rather than Constraint_Error, because the main reason for such values is uninitialized variables, and the normal way to indicate such a use (if detected) is to raise Program_Error. (Other reasons would involve the misuse of low-level features such as Unchecked_Conversion.)

NOTE 1 Indexing and loop iteration use values of discrete types.

NOTE 2 The predefined operations of a discrete type include the assignment operation, qualification, the membership tests, and the relational operators; for a boolean type they include the short-circuit control forms and the logical operators; for an integer type they include type conversion to and from other numeric types, as well as the binary and unary adding operators – and +, the multiplying operators, the unary operator **abs**, and the exponentiation operator. The assignment operation is described in 5.2. The other predefined operations are described in Clause 4.

NOTE 4 For a subtype of a discrete type, the result delivered by the attribute Val can be outside the subtype; similarly, the actual parameter of the attribute Pos can also be outside the subtype. The following relations are satisfied (in the absence of an exception) by these attributes:

S'Val(S'Pos(X)) = X
S'Pos(S'Val(N)) = N

#### Examples

14*Examples of attributes of discrete subtypes: *

-- For the types and subtypes declared in 3.5.1 the following hold:
16
-- Color'First = White, Color'Last = Black
-- Rainbow'First = Red, Rainbow'Last = Blue
17
-- Color'Succ(Blue) = Rainbow'Succ(Blue) = Brown
-- Color'Pos(Blue) = Rainbow'Pos(Blue) = 4
-- Color'Val(0) = Rainbow'Val(0) = White

#### Extensions to Ada 83

The attributes S'Succ, S'Pred, S'Width, S'Image, and S'Value have been generalized to apply to real types as well (see 3.5, “Scalar Types”).

#### Extensions to Ada 2005

#### Wording Changes from Ada 2012

**Corrigendum:** Updated wording of the attributes S'First_Valid and S'Last_Valid to use the new term "satisfies the predicates" (see 3.2.4).

## 3.5.6 Real Types

1Real types provide approximations to the real numbers, with relative bounds on errors for floating point types, and with absolute bounds for fixed point types.

#### Syntax

2`real_type_definition`

` ::= `

`floating_point_definition`

| `fixed_point_definition`

#### Static Semantics

3A type defined by a `real_type_definition`

is implicitly derived from *root_real*, an anonymous predefined (specific) real type. [Hence, all real types, whether floating point or fixed point, are in the derivation class rooted at *root_real*.]

It is not specified whether the derivation from *root_real* is direct or indirect, not that it really matters. All we want is for all real types to be descendants of *root_real*.

{*8652/0099*} Note that this derivation does not imply any inheritance of subprograms. Subprograms are inherited only for types derived by a `derived_type_definition`

(see 3.4), or a `private_extension_declaration`

(see 7.3, 7.3.1, and 12.5.1).

[ Real literals are all of the type *universal_real*, the universal type (see 3.4.1) for the class rooted at *root_real*, allowing their use with the operations of any real type. Certain multiplying operators have a result type of *universal_fixed* (see 4.5.5), the universal type for the class of fixed point types, allowing the result of the multiplication or division to be used where any specific fixed point type is expected.]

#### Dynamic Semantics

5The elaboration of a `real_type_definition`

consists of the elaboration of the `floating_point_definition`

or the `fixed_point_definition`

.

#### Implementation Requirements

6An implementation shall perform the run-time evaluation of a use of a predefined operator of *root_real* with an accuracy at least as great as that of any floating point type definable by a `floating_point_definition`

.

Static calculations using the operators of *root_real* are exact, as for all static calculations. See 4.9.

The Digits attribute of the type used to represent *root_real* at run time is at least as great as that of any other floating point type defined by a `floating_point_definition`

, and its safe range includes that of any such floating point type with the same Digits attribute. On some machines, there might be real types with less accuracy but a wider range, and hence run-time calculations with *root_real* might not be able to accommodate all values that can be represented at run time in such floating point or fixed point types.

#### Implementation Permissions

7/5[For the execution of a predefined operation of a real type, it is optional to raise Constraint_Error if the result is outside the base range of the type, so long as the correct result is produced, or the Machine_Overflows attribute of the type is False (see G.2.1).]

An implementation may provide *nonstandard real types*, descendants of *root_real* that are declared outside of the specification of package Standard, which may have different characteristics than a type defined by a `real_type_definition`

. For example, a nonstandard real type can have an asymmetric or unsigned base range, or its predefined operations can wrap around or “saturate” rather than overflow (modular or saturating arithmetic), or it can have a different accuracy model than is standard (see G.2.1). Any type descended from a nonstandard real type is also nonstandard. An implementation may place arbitrary restrictions on the use of such types; it is implementation defined whether operators that are predefined for “any real type” are defined for a particular nonstandard real type. [In any case, such types are not permitted as `explicit_generic_actual_parameter`

s for formal scalar types — see 12.5.2.]

Any nonstandard real types and the operators defined for them.

NOTE As stated, real literals are of the anonymous predefined real type *universal_real*. Other real types have no literals. However, the overload resolution rules (see 8.6) allow expressions of the type *universal_real* whenever a real type is expected.

#### Wording Changes from Ada 83

The syntax rule for `real_type_definition`

is modified to use the new syntactic categories `floating_point_definition`

and `fixed_point_definition`

, instead of `floating_point_constraint`

and `fixed_point_constraint`

, because the semantics of a type definition are significantly different than the semantics of a constraint.

## 3.5.7 Floating Point Types

1For floating point types, the error bound is specified as a relative precision by giving the required minimum number of significant decimal digits.

#### Syntax

2`floating_point_definition`

` ::= `

**digits** *static_*`expression`

[`real_range_specification`

]

3
`real_range_specification`

` ::= `

**range** *static_*`simple_expression`

.. *static_*`simple_expression`

#### Name Resolution Rules

4The *requested decimal precision*, which is the minimum number of significant decimal digits required for the floating point type, is specified by the value of the `expression`

given after the reserved word **digits**. This `expression`

is expected to be of any integer type.

Each `simple_expression`

of a `real_range_specification`

is expected to be of any real type[; the types can be different].

#### Legality Rules

6The requested decimal precision shall be specified by a static `expression`

whose value is positive and no greater than System.Max_Base_Digits. Each `simple_expression`

of a `real_range_specification`

shall also be static. If the `real_range_specification`

is omitted, the requested decimal precision shall be no greater than System.Max_Digits.

We have added Max_Base_Digits to package System. It corresponds to the requested decimal precision of *root_real*. System.Max_Digits corresponds to the maximum value for Digits that may be specified in the absence of a `real_range_specification`

, for upward compatibility. These might not be the same if *root_real* has a base range that does not include ± 10.0**(4*Max_Base_Digits).

A `floating_point_definition`

is illegal if the implementation does not support a floating point type that satisfies the requested decimal precision and range.

What combinations of requested decimal precision and range are supported for floating point types.

#### Static Semantics

8The set of values for a floating point type is the (infinite) set of rational numbers. The *machine numbers* of a floating point type are the values of the type that can be represented exactly in every unconstrained variable of the type. The base range (see 3.5) of a floating point type is symmetric around zero, except that it can include some extra negative values in some implementations.

For example, if a 2's complement representation is used for the mantissa rather than a sign-mantissa or 1's complement representation, then there is usually one extra negative machine number.

**To be honest: **If the Signed_Zeros attribute is True, then minus zero could in a sense be considered a value of the type. However, for most purposes, minus zero behaves the same as plus zero.

The *base decimal precision* of a floating point type is the number of decimal digits of precision representable in objects of the type. The *safe range* of a floating point type is that part of its base range for which the accuracy corresponding to the base decimal precision is preserved by all predefined operations.

In most cases, the safe range and base range are the same. However, for some hardware, values near the boundaries of the base range might result in excessive inaccuracies or spurious overflows when used with certain predefined operations. For such hardware, the safe range would omit such values.

A `floating_point_definition`

defines a floating point type whose base decimal precision is no less than the requested decimal precision. If a `real_range_specification`

is given, the safe range of the floating point type (and hence, also its base range) includes at least the values of the simple expressions given in the `real_range_specification`

. If a `real_range_specification`

is not given, the safe (and base) range of the type includes at least the values of the range –10.0**(4*D) .. +10.0**(4*D) where D is the requested decimal precision. [The safe range can include other values as well. The attributes Safe_First and Safe_Last give the actual bounds of the safe range.]

A `floating_point_definition`

also defines a first subtype of the type. If a `real_range_specification`

is given, then the subtype is constrained to a range whose bounds are given by a conversion of the values of the `simple_expression`

s of the `real_range_specification`

to the type being defined. Otherwise, the subtype is unconstrained.

**To be honest: **The conversion mentioned above is not an *implicit subtype conversion* (which is something that happens at overload resolution, see 4.6), although it happens implicitly. Therefore, the freezing rules are not invoked on the type (which is important so that representation items can be given for the type).

There is a predefined, unconstrained, floating point subtype named Float[, declared in the visible part of package Standard].

#### Dynamic Semantics

13[The elaboration of a `floating_point_definition`

creates the floating point type and its first subtype.]

#### Implementation Requirements

14In an implementation that supports floating point types with 6 or more digits of precision, the requested decimal precision for Float shall be at least 6.

If Long_Float is predefined for an implementation, then its requested decimal precision shall be at least 11.

#### Implementation Permissions

16/5An implementation is allowed to provide additional predefined floating point types[, declared in the visible part of Standard], whose (unconstrained) first subtypes have names of the form Short_Float, Long_Float, Short_Short_Float, Long_Long_Float, etc. Different predefined floating point types are allowed to have the same base decimal precision. However, the precision of Float should be no greater than that of Long_Float. Similarly, the precision of Short_Float (if provided) should be no greater than Float. Corresponding recommendations apply to any other predefined floating point types. An implementation may support base decimal precisions for which there is no corresponding named floating point type.

The predefined floating point types declared in Standard.

#### Implementation Advice

17An implementation should support Long_Float in addition to Float if the target machine supports 11 or more digits of precision. No other named floating point subtypes are recommended for package Standard. Instead, appropriate named floating point subtypes should be provided in the library package Interfaces (see B.2).

Long_Float should be declared in Standard if the target supports 11 or more digits of precision. No other named float subtypes should be declared in Standard.

To promote portability, implementations should explicitly declare the floating point (sub)types Float and Long_Float in Standard, and leave other predefined float types anonymous. For implementations that already support Short_Float, etc., upward compatibility argues for keeping such declarations in Standard during the transition period, but perhaps generating a warning on use. A separate package Interfaces in the predefined environment is available for pre-declaring types such as Float_32, IEEE_Float_64, etc. See B.2.

NOTE If a floating point subtype is unconstrained, then assignments to variables of the subtype involve only Overflow_Checks, never Range_Checks.

#### Examples

19*Examples of floating point types and subtypes:*

type Coefficient is digits 10 range -1.0 .. 1.0;
21
type Real is digits 8;
type Mass is digits 7 range 0.0 .. 1.0E35;
22
subtype Probability is Real range 0.0 .. 1.0;
-- a subtype with a smaller range

#### Inconsistencies With Ada 83

No Range_Checks, only Overflow_Checks, are performed on variables (or parameters) of an unconstrained floating point subtype. This is upward compatible for programs that do not raise Constraint_Error. For those that do raise Constraint_Error, it is possible that the exception will be raised at a later point, or not at all, if extended range floating point registers are used to hold the value of the variable (or parameter).

This change was felt to be justified by the possibility of improved performance on machines with extended-range floating point registers. An implementation need not take advantage of this relaxation in the range checking; it can hide completely the use of extended range registers if desired, presumably at some run-time expense.

#### Wording Changes from Ada 83

The syntax rules for `floating_point_constraint`

and `floating_accuracy_definition`

are removed. The syntax rules for `floating_point_definition`

and `real_range_specification`

are new.

A syntax rule for `digits_constraint`

is given in 3.5.9, “Fixed Point Types”. In J.3 we indicate that a `digits_constraint`

may be applied to a floating point `subtype_mark`

as well (to be compatible with Ada 83's `floating_point_constraint`

).

Discussion of model numbers is postponed to 3.5.8 and G.2. The concept of safe numbers has been replaced by the concept of the safe range of values. The bounds of the safe range are given by T'Safe_First .. T'Safe_Last, rather than -T'Safe_Large .. T'Safe_Large, since on some machines the safe range is not perfectly symmetric. The concept of machine numbers is new, and is relevant to the definition of Succ and Pred for floating point numbers.

## 3.5.8 Operations of Floating Point Types

#### Static Semantics

1The following attribute is defined for every floating point subtype S:

S'Digits

- {
*8652/0004*} S'Digits denotes the requested decimal precision for the subtype S. The value of this attribute is of the type*universal_integer*. The requested decimal precision of the base subtype of a floating point type*T*is defined to be the largest value of*d*for which

ceiling(*d** log(10) / log(T'Machine_Radix)) +*g*<= T'Model_Mantissa

where g is 0 if Machine_Radix is a positive power of 10 and 1 otherwise.

NOTE 1 The predefined operations of a floating point type include the assignment operation, qualification, the membership tests, and explicit conversion to and from other numeric types. They also include the relational operators and the following predefined arithmetic operators: the binary and unary adding operators – and +, certain multiplying operators, the unary operator **abs**, and the exponentiation operator.

#### Wording Changes from Ada 95

## 3.5.9 Fixed Point Types

1A fixed point type is either an ordinary fixed point type, or a decimal fixed point type. The error bound of a fixed point type is specified as an absolute value, called the *delta* of the fixed point type.

#### Syntax

2`fixed_point_definition`

` ::= `

`ordinary_fixed_point_definition`

| `decimal_fixed_point_definition`

3
`ordinary_fixed_point_definition`

` ::= `

**delta***static_*`expression`

`real_range_specification`

4
`decimal_fixed_point_definition`

` ::= `

**delta** *static_*`expression`

**digits** *static_*`expression`

[`real_range_specification`

]

5/4
`digits_constraint`

` ::= `

**digits** *static_*`simple_expression`

[`range_constraint`

]

#### Name Resolution Rules

6For a type defined by a `fixed_point_definition`

, the *delta* of the type is specified by the value of the `expression`

given after the reserved word **delta**; this `expression`

is expected to be of any real type. For a type defined by a `decimal_fixed_point_definition`

(a *decimal* fixed point type), the number of significant decimal digits for its first subtype (the *digits* of the first subtype) is specified by the `expression`

given after the reserved word **digits**; this `expression`

is expected to be of any integer type.

The `simple_expression`

of a `digits_constraint`

is expected to be of any integer type.

#### Legality Rules

7In a `fixed_point_definition`

or `digits_constraint`

, the `expression`

s given after the reserved words **delta** and **digits** shall be static; their values shall be positive.

The set of values of a fixed point type comprise the integral multiples of a number called the *small* of the type. The *machine numbers* of a fixed point type are the values of the type that can be represented exactly in every unconstrained variable of the type. For a type defined by an `ordinary_fixed_point_definition`

(an *ordinary* fixed point type), the *small* may be specified by an `attribute_definition_clause`

(see 13.3); if so specified, it shall be no greater than the *delta* of the type. If not specified, the *small* of an ordinary fixed point type is an implementation-defined power of two less than or equal to the *delta*.

The *small* of an ordinary fixed point type.

For a decimal fixed point type, the *small* equals the *delta*; the *delta* shall be a power of 10. If a `real_range_specification`

is given, both bounds of the range shall be in the range –(10***digits*–1)**delta* .. +(10***digits*–1)**delta*.

A `fixed_point_definition`

is illegal if the implementation does not support a fixed point type with the given *small* and specified range or *digits*.

What combinations of *small*, range, and *digits* are supported for fixed point types.

For a `subtype_indication`

with a `digits_constraint`

, the `subtype_mark`

shall denote a decimal fixed point subtype.

#### Static Semantics

12The base range (see 3.5) of a fixed point type is symmetric around zero, except possibly for an extra negative value in some implementations.

An `ordinary_fixed_point_definition`

defines an ordinary fixed point type whose base range includes at least all multiples of *small* that are between the bounds specified in the `real_range_specification`

. The base range of the type does not necessarily include the specified bounds themselves. An `ordinary_fixed_point_definition`

also defines a constrained first subtype of the type, with each bound of its range given by the closer to zero of:

- the value of the conversion to the fixed point type of the corresponding
`expression`

of the`real_range_specification`

;

**To be honest: **The conversion mentioned above is not an *implicit subtype conversion* (which is something that happens at overload resolution, see 4.6), although it happens implicitly. Therefore, the freezing rules are not invoked on the type (which is important so that representation items can be given for the type).

- the corresponding bound of the base range.

A `decimal_fixed_point_definition`

defines a decimal fixed point type whose base range includes at least the range –(10***digits*–1)**delta* .. +(10***digits*–1)**delta*. A `decimal_fixed_point_definition`

also defines a constrained first subtype of the type. If a `real_range_specification`

is given, the bounds of the first subtype are given by a conversion of the values of the `expression`

s of the `real_range_specification`

. Otherwise, the range of the first subtype is –(10***digits*–1)**delta* .. +(10***digits*–1)**delta*.

**To be honest: **The conversion mentioned above is not an *implicit subtype conversion* (which is something that happens at overload resolution, see 4.6), although it happens implicitly. Therefore, the freezing rules are not invoked on the type (which is important so that representation items can be given for the type).

#### Dynamic Semantics

17The elaboration of a `fixed_point_definition`

creates the fixed point type and its first subtype.

For a `digits_constraint`

on a decimal fixed point subtype with a given *delta*, if it does not have a `range_constraint`

, then it specifies an implicit range –(10***D*–1)**delta* .. +(10***D*–1)**delta*, where *D* is the value of the `simple_expression`

. A `digits_constraint`

is *compatible* with a decimal fixed point subtype if the value of the `simple_expression`

is no greater than the *digits* of the subtype, and if it specifies (explicitly or implicitly) a range that is compatible with the subtype.

Except for the requirement that the *digits* specified be no greater than the *digits* of the subtype being constrained, a `digits_constraint`

is essentially equivalent to a `range_constraint`

.

Consider the following example:

type D is delta 0.01 digits 7 range -0.00 .. 9999.99;

The compatibility rule implies that the `digits_constraint`

"**digits** 6" specifies an implicit range of "–9999.99 .. 9999.99". Thus, "**digits** 6" is not compatible with the constraint of D, but "**digits** 6 range 0.00 .. 9999.99" is compatible.

A value of a scalar type belongs to a constrained subtype of the type if it belongs to the range of the subtype. Attributes like Digits and Delta have no effect on this fundamental rule. So the obsolescent forms of `digits_constraint`

s and `delta_constraint`

s that are called “accuracy constraints” in RM83 don't really represent constraints on the values of the subtype, but rather primarily affect compatibility of the “constraint” with the subtype being “constrained”. In this sense, they might better be called “subtype assertions” rather than “constraints”.

Note that the `digits_constraint`

on a decimal fixed point subtype is a combination of an assertion about the *digits* of the subtype being further constrained, and a constraint on the range of the subtype being defined, either explicit or implicit.

The elaboration of a `digits_constraint`

consists of the elaboration of the `range_constraint`

, if any. If a `range_constraint`

is given, a check is made that the bounds of the range are both in the range –(10***D*–1)**delta* .. +(10***D*–1)**delta*, where *D* is the value of the (static) `simple_expression`

given after the reserved word **digits**. If this check fails, Constraint_Error is raised.

#### Implementation Requirements

20The implementation shall support at least 24 bits of precision (including the sign bit) for fixed point types.

This is sufficient to represent Standard.Duration with a *small* no more than 50 milliseconds.

#### Implementation Permissions

21Implementations are permitted to support only *small*s that are a power of two. In particular, all decimal fixed point type declarations can be disallowed. Note however that conformance with the Information Systems Annex requires support for decimal *small*s, and decimal fixed point type declarations with *digits* up to at least 18.

The accuracy requirements for multiplication, division, and conversion (see G.2.1, “Model of Floating Point Arithmetic”) are such that support for arbitrary *small*s should be practical without undue implementation effort. Therefore, implementations should support fixed point types with arbitrary values for *small* (within reason). One reasonable limitation would be to limit support to fixed point types that can be converted to the most precise floating point type without loss of precision (so that Fixed_IO is implementable in terms of Float_IO).

NOTE The specified bounds themselves can be outside the base range of an ordinary fixed point type so that the range specification can be given in a natural way, such as:

type Fraction is delta 2.0**(-15) range -1.0 .. 1.0;

With 2's complement hardware, such a type would typically have a signed 16-bit representation, using 1 bit for the sign and 15 bits for fraction, resulting in a base range of –1.0 .. 1.0–2.0**(–15).

#### Examples

25*Examples of fixed point types and subtypes:*

type Volt is delta 0.125 range 0.0 .. 255.0;
27
-- A pure fraction which requires all the available
-- space in a word can be declared as the type Fraction:
type Fraction is delta System.Fine_Delta range -1.0 .. 1.0;
-- Fraction'Last = 1.0 – System.Fine_Delta
28
type Money is delta 0.01 digits 15; -- decimal fixed point
subtype Salary is Money digits 10;
-- Money'Last = 10.0**13 – 0.01, Salary'Last = 10.0**8 – 0.01

#### Inconsistencies With Ada 83

In Ada 95, S'Small always equals S'Base'Small, so if an implementation chooses a *small* for a fixed point type smaller than required by the *delta*, the value of S'Small in Ada 95 might not be the same as it was in Ada 83.

#### Extensions to Ada 83

Decimal fixed point types are new, though their capabilities are essentially similar to that available in Ada 83 with a fixed point type whose *small* equals its *delta* and both are a power of 10. However, in the Information Systems Annex, additional requirements are placed on the support of decimal fixed point types (e.g. a minimum of 18 digits of precision).

#### Wording Changes from Ada 83

The syntax rules for `fixed_point_constraint`

and `fixed_accuracy_definition`

are removed. The syntax rule for `fixed_point_definition`

is new. A syntax rule for `delta_constraint`

is included in the Obsolescent features (to be compatible with Ada 83's `fixed_point_constraint`

).

#### Wording Changes from Ada 95

Added wording to define the machine numbers of fixed point types; this is needed by the static evaluation rules.

#### Incompatibilities With Ada 2012

**Corrigendum:** Changed the syntax so that the value following **digits** in a `digits_constraint`

is a `simple_expression`

. This is compatible with one very unlikely exception: if the **digits** expression is a static expression of a modular type using an unparenthesized logical operator (like **and** or **or**). Parenthesizing the expression will make it legal in that case. The change is necessary to eliminate syntax ambguities in `derived_type_definition`

s.

#### Wording Changes from Ada 2012

**Corrigendum**:Added wording to define the expected type for a `digits_constraint`

. This was missing since Ada 95, but as it is obvious and unchanged from Ada 83, we don't consider it an incompatibility.

## 3.5.10 Operations of Fixed Point Types

#### Static Semantics

1The following attributes are defined for every fixed point subtype S:

S'Small

- {
*8652/0005*} S'Small denotes the*small*of the type of S. The value of this attribute is of the type*universal_real*. Small may be specified for nonderived ordinary fixed point types via an`attribute_definition_clause`

(see 13.3); the expression of such a clause shall be static and positive.

**Aspect Description for ****Small: **Scale factor for a fixed point type.

S'Delta

- S'Delta denotes the
*delta*of the fixed point subtype S. The value of this attribute is of the type*universal_real*.

The *delta* is associated with the *sub*type as opposed to the type, because of the possibility of an (obsolescent) `delta_constraint`

.

S'Fore

- S'Fore yields the minimum number of characters needed before the decimal point for the decimal representation of any value of the subtype S, assuming that the representation does not include an exponent, but includes a one-character prefix that is either a minus sign or a space. (This minimum number does not include superfluous zeros or underlines, and is at least 2.) The value of this attribute is of the type
*universal_integer*. 5

S'Aft- S'Aft yields the number of decimal digits needed after the decimal point to accommodate the
*delta*of the subtype S, unless the*delta*of the subtype S is greater than 0.1, in which case the attribute yields the value one. [(S'Aft is the smallest positive integer N for which (10**N)*S'Delta is greater than or equal to one.)] The value of this attribute is of the type*universal_integer*.

The following additional attributes are defined for every decimal fixed point subtype S:

S'Digits

- S'Digits denotes the
*digits*of the decimal fixed point subtype S, which corresponds to the number of decimal digits that are representable in objects of the subtype. The value of this attribute is of the type*universal_integer*. Its value is determined as follows:

- For a first subtype or a subtype defined by a
`subtype_indication`

with a`digits_constraint`

, the digits is the value of the expression given after the reserved word**digits**; 9/5 - For a subtype defined by a
`subtype_indication`

without a`digits_constraint`

, the digits of the subtype is the same as that of the subtype denoted by the`subtype_mark`

in the`subtype_indication`

;

Although a decimal subtype can be both range-constrained and digits-constrained, the digits constraint is intended to control the Size attribute of the subtype. For decimal types, Size can be important because input/output of decimal types is so common.

- The digits of a base subtype is the largest integer
*D*such that the range –(10***D*–1)**delta*.. +(10***D*–1)**delta*is included in the base range of the type.

S'Scale

- S'Scale denotes the
*scale*of the subtype S, defined as the value N such that S'Delta = 10.0**(–N). [The scale indicates the position of the point relative to the rightmost significant digits of values of subtype S.] The value of this attribute is of the type*universal_integer*.

S'Scale is negative if S'Delta is greater than one. By contrast, S'Aft is always positive.

S'Round

- S'Round denotes a function with the following specification:

function S'Round(X : universal_real)
return S'Base

14
- The function returns the value obtained by rounding X (away from 0, if X is midway between two values of the type of S).

NOTE 1 All subtypes of a fixed point type will have the same value for the Delta attribute, in the absence of `delta_constraint`

s (see J.3).

NOTE 2 S'Scale is not always the same as S'Aft for a decimal subtype; for example, if S'Delta = 1.0 then S'Aft is 1 while S'Scale is 0.

NOTE 3 The predefined operations of a fixed point type include the assignment operation, qualification, the membership tests, and explicit conversion to and from other numeric types. They also include the relational operators and the following predefined arithmetic operators: the binary and unary adding operators – and +, multiplying operators, and the unary operator **abs**.

#### Wording Changes from Ada 95

{*8652/0005*} **Corrigendum:** Clarified that *small* may be specified only for ordinary fixed point types.