This Reference Manual output has not been verified, and may contain omissions or errors. Report any problems on the tracking issue
[ A literal represents a value literally, that is, by means of notation suited to its kind.] A literal is either a
character_literal, the literal null, or a
identifierrather than a
character_literalis not considered a literal in the above sense, because it involves no special notation “suited to its kind”. It might more properly be called an
enumeration_identifier, except for historical reasons.
Name Resolution Rules2/2
This paragraph was deleted.
name that consists of a
character_literal, either its expected type shall be a single character type, in which case it is interpreted as a parameterless
function_call that yields the corresponding value of the character type, or its expected profile shall correspond to a parameterless function with a character result type, in which case it is interpreted as the name of the corresponding parameterless function declared as part of the character type's definition (see 3.5.1). In either case, the
character_literal denotes the
selector_namethat is a
The expected type for a
primary that is a
string_literal shall be a single string type or a type with a specified String_Literal aspect (see 4.2.1). In either case, the
string_literal is interpreted to be of its expected type. If the expected type of an integer literal is a type with a specified Integer_Literal aspect (see 4.2.1), the literal is interpreted to be of its expected type; otherwise it is interpreted to be of type universal_integer. If the expected type of a real literal is a type with a specified Real_Literal aspect (see 4.2.1), it is interpreted to be of its expected type; otherwise, it is interpreted to be of type universal_real.
character_literal that is a
name shall correspond to a
defining_character_literal of the expected type, or of the result type of the expected profile.
If the expected type for a string_literal is a string type, then for each character of the
string_literal there shall be a corresponding
defining_character_literal of the component type of the expected string type.
This paragraph was deleted.
The literal null is of type universal_access.
If its expected type is a numeric type, the evaluation of a numeric literal yields the represented value. [In other cases, the effect of evaluating a numeric literal is determined by the Integer_Literal or Real_Literal aspect that applies (see 4.2.1).]
The evaluation of the literal null yields the null value of the expected type.
The evaluation of a
string_literal that is a
primary and has an expected type that is a string type, yields an array value containing the value of each character of the sequence of characters of the
string_literal, as defined in 2.6. The bounds of this array value are determined according to the rules for
positional_array_aggregates (see 4.3.3), except that for a null string literal, the upper bound is the predecessor of the lower bound. [In other cases, the effect of evaluating a
string_literal is determined by the String_Literal aspect that applies (see 4.2.1).]
For the evaluation of a
string_literal of a string type T, a check is made that the value of each character of the
string_literal belongs to the component subtype of T. For the evaluation of a null string literal of a string type, a check is made that its lower bound is greater than the lower bound of the base range of the index type. The exception Constraint_Error is raised if either of these checks fails.
identifiers rather than
character_literals follow the normal rules for
identifiers when used in a
name(see 4.1 and 4.1.3).
Character_literals used as
selector_names follow the normal rules for expanded names (see 4.1.3).
Examples of literals:
3.14159_26536 -- a real literal
1_345 -- an integer literal
'A' -- a character literal
"Some Text" -- a string literal
Incompatibilities With Ada 83
character_literals are now treated like other literals, in that they are resolved using context rather than depending on direct visibility, additional qualification might be necessary when passing a
character_literalto an overloaded subprogram.
Extensions to Ada 83
Character_literals are now treated analogously to null and
string_literals, in that they are resolved using context, rather than their content; the declaration of the corresponding
defining_character_literalneed not be directly visible.
Wording Changes from Ada 83
character_literals are not included anymore, since they are neither syntactically nor semantically "literals" but are rather names of parameterless functions.
Extensions to Ada 95
Wording Changes from Ada 2012
4.2.1 User-Defined Literals1/5
Using one or more of the aspects defined below, a type may be specified to allow the use of one or more kinds of literals as values of the type.
The following type-related operational aspects (collectively known as user-defined literal aspects) may be specified for a type T:
- This aspect is specified by a function_
namethat statically denotes a function with a result type of T and one in parameter that is of type String and is not explicitly aliased.
- This aspect is specified by a function_
namethat statically denotes a function with a result type of T and one in parameter that is of type String and is not explicitly aliased, and optionally a second function [(overloading the first) ]with a result type of T and two in parameters of type String that are not explicitly aliased.
- This aspect is specified by a function_
namethat statically denotes a function with a result type of T and one in parameter that is of type Wide_Wide_String and is not explicitly aliased.
aspect_definitionfor an aspect that is defined to be a subprogram is based on the profile required for that aspect (see 13.1.1):
package Pkg1 is
type T is record X, Y : Integer; end record
with Integer_Literal => Int_Lit;
function Int_Lit (X, Y : T) return Duration; -- Wrong profile.
function Int_Lit (Lit_Image : String) return T; -- Right profile.
User-defined literal aspects are nonoverridable (see 13.1.1).
package Pkg2 is type T1 is record X, Y : Integer; end record with Integer_Literal => I_L; 6.c/5function I_L (S : String) return T1 is ((0, 0)); 6.d/5type T2 is new T1; function I_L (S : String) return T2 is ((1, 1)); X : T2 := 123; end Pkg2;
When a numeric literal is interpreted as a value of a non-numeric type T or a
string_literal is interpreted as a value of a type T that is not a string type (see 4.2), it is equivalent to a call to the subprogram denoted by the corresponding aspect of T: the Integer_Literal aspect for an integer literal, the Real_Literal aspect for a real literal, and the String_Literal aspect for a
string_literal. The actual parameter of this notional call is a
string_literal representing a sequence of characters that is the same as the sequence of characters in the original numeric literal, or the sequence represented by the original string literal.
string_literalare defined by the usual rules for the bounds of a
Such a literal is said to be a user-defined literal.
When a named number that denotes a value of type universal_integer is interpreted as a value of a non-numeric type T, it is equivalent to a call to the function denoted by the Integer_Literal aspect of T. The actual parameter of this notional call is a String having a textual representation of a decimal integer literal optionally preceded by a minus sign, representing the same value as the named number.
When a named number that denotes a value of type universal_real is interpreted as a value of a non-numeric type T, it is equivalent to a call to the two-parameter function denoted by the Real_Literal aspect of T, if any. The actual parameters of this notional call are each a String with the textual representation of a decimal integer literal, with the first optionally preceded by a minus sign, where the first String represents the same value as the numerator, and the second the same value as the denominator, of the named number when represented as a rational number in lowest terms, with a positive denominator.
The Integer_Literal or Real_Literal aspect shall not be specified for a type T if the full view of T is a numeric type. The String_Literal aspect shall not be specified for a type T if the full view of T is a string type.
For a nonabstract type, the function directly specified for a user-defined literal aspect shall not be abstract.
For a tagged type with a partial view, a user-defined literal aspect shall not be directly specified on the full type.
If a nonabstract tagged type inherits any user-defined literal aspect, then each inherited aspect shall be directly specified as a nonabstract function for the type unless the inherited aspect denotes a nonabstract function, or functions, and the type is a null extension.
If a named number that denotes a value of type universal_integer is interpreted as a value of a non-numeric type T, T shall have an Integer_Literal aspect. If a named number that denotes a value of type universal_real is interpreted as a value of a non-numeric type T, T shall have a Real_Literal aspect, and the aspect shall denote a function that has two in parameters, both of type String, with result of type T.
In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit.
Bounded (Run-Time) Errors17/5
It is a bounded error if the evaluation of a literal or named number that has an expected type with a specified user-defined literal aspect propagates an exception. Either Program_Error or the exception propagated by the evaluation is raised at the point of use of the value of the literal or named number. If it is recognized prior to run time that evaluation of such a literal or named number will inevitably (if executed) result in such a bounded error, then this may be reported as an error prior to run time.
- The implementation can evaluate a user-defined literal function at compile-time if it has access to the body of the function (for example, if it is inlined), and that body doesn't reference anything evaluated at runtime. If the compile-time evaluation results in an exception, this bounded error allows the compilation unit to be rejected.
- Implementations can use existing permissions (see 6.1.2) to avoid evaluating the function associated with a user-defined literal more than once for a particular literal value. This evaluation can be "hoisted" (done once per compilation unit during the elaboration of the unit) if the compiler can prove that the function doesn't depend on any constants or locals with a runtime value not yet elaborated.
- If the literal value is not needed by the execution of the program, the function call can be omitted even if it might have side-effects (again, see 6.1.2).
Examples of the specification and use of user-defined literals:
subtype Roman_Character is Wide_Wide_Character with Static_Predicate => Roman_Character in 'I' | 'V' | 'X' | 'L' | 'C' | 'D' | 'M'; 20/5Max_Roman_Number : constant := 3_999; -- MMMCMXCIX 21/5type Roman_Number is range 1 .. Max_Roman_Number with String_Literal => To_Roman_Number; 22/5function To_Roman_Number (S : Wide_Wide_String) return Roman_Number with Pre => S'Length > 0 and then (for all Char of S => Char in Roman_Character); 23/5function To_Roman_Number (S : Wide_Wide_String) return Roman_Number is (declare R : constant array (Integer range <>) of Roman_Number := (for D in S'Range => Roman_Digit'Enum_Rep (Roman_Digit'Wide_Wide_Value (''' & S(D) & '''))); -- See 3.5.2 and 13.4 begin [for I in R'Range => (if I < R'Last and then R(I) < R(I + 1) then -1 else 1) * R(I)] 'Reduce("+", 0) ); 24/5X : Roman_Number := "III" * "IV" * "XII"; -- 144 (that is, CXLIV)