Discussion: The concept of the value
of a limited type is difficult to define, since the abstract value of
a limited type often extends beyond its physical representation. In some
sense, values of a limited type cannot be divorced from their object.
The value is the object.

{AI95-00318-02}
In Ada 83, in the two places where limited types were defined by the
language, namely tasks and files, an implicit level of indirection was
implied by the semantics to avoid the separation of the value from an
associated object. In Ada 95, most limited types are passed by reference,
and even return-ed by reference. In Ada 2005, most limited types are
built-in-place upon return, rather than returned by reference. Thus the
object “identity” is part of the logical value of most limited
types.

To be honest: {AI95-00287-01}
{AI95-00419-01}
For a limited partial view whose full view is nonlimited, copying is
possible on parameter passing and function return. To prevent any copying
whatsoever, one should make both the partial and full views limited.

Legality Rules

{AI95-00419-01}
If a tagged record type has any limited components, then the reserved
word limited shall appear in its record_type_definition.
[If the reserved word limited appears in the definition of a derived_type_definition,
its parent type and any progenitor interfaces shall be limited.]

Proof: {AI95-00419-01}
The rule about the parent type being required to be limited can be found
in 3.4. Rules about progenitor interfaces can
be found in 3.9.4, specifically, a nonlimited
interface can appear only on a nonlimited type. We repeat these rules
here to gather these scattered rules in one obvious place.

To be honest: {AI95-00419-01}
A derived type can become nonlimited if limited does not appear
and the derivation takes place in the visible part of a child package,
and the parent type is nonlimited as viewed from the private part or
body of the child package.

Reason: {AI95-00419-01}
We considered a rule where limitedness was always inherited from the
parent for derived types, but in the case of a type whose parent is an
interface, this meant that the first interface is treated differently
than other interfaces. It also would have forced users to declare dummy
nonlimited interfaces just to get the limitedness right. We also considered
a syntax like not limited to specify nonlimitedness when the parent
was limited, but that was unsavory. The rule given is more uniform and
simpler to understand.

{AI95-00419-01}
The rules for interfaces are asymmetrical, but the language is not: if
the parent interface is limited, the presence of the word limited
determines the limitedness, and nonlimited progenitors are illegal by
the rules in 3.9.4 if limited is present.
If the parent interface is nonlimited, the word limited is illegal
by the rules in 3.4. The net effect is that
the order of the interfaces doesn't matter.

Reason: The full type in both of these
cases must necessarily be immutably limited. We need to include private
types as much as possible so that we aren't unintentionally discouraging
the use of private types.

Discussion: An immutably limited type
is a type that cannot become nonlimited subsequently in a private part
or in a child unit. If a view of the type makes it immutably limited,
then no copying (assignment) operations are ever available for objects
of the type. This allows other properties; for instance, it is safe for
such objects to have access discriminants that have defaults or designate
other limited objects.

{AI05-0052-1}
A descendant of a generic formal limited private type is presumed to
be immutably limited except within the body of a generic unit or a body
declared within the declarative region of a generic unit, if the formal
type is declared within the formal part of the generic unit.

Ramification: In an instance, a type
is descended from the actual type corresponding to the formal, and all
rules are rechecked in the specification. Bodies are excepted so that
we assume the worst there; the complex wording is required to handle
children of generics and unrelated bodies properly.

It is important to remember that a single nonprivate
type can be both limited and nonlimited in different parts of its scope.
In other words, “limited” is a property that depends on where
you are in the scope of the type. We don't call this a “view property”
because there is no particular declaration to declare the nonlimited
view.

18 Notes on the example: In the
example above, an outside subprogram making use of IO_Package may obtain
a file name by calling Open and later use it in calls to Read and Write.
Thus, outside the package, a file name obtained from Open acts as a kind
of password; its internal properties (such as containing a numeric value)
are not known and no other operations (such as addition or comparison
of internal names) can be performed on a file name. Most importantly,
clients of the package cannot make copies of objects of type File_Name.

This example is characteristic of any case where complete
control over the operations of a type is desired. Such packages serve
a dual purpose. They prevent a user from making use of the internal structure
of the type. They also implement the notion of an encapsulated data type
where the only operations on the type are those given in the package
specification.

{AI95-00318-02}
The fact that the full view of File_Name is explicitly declared limited
means that parameter passing will always be by reference and function
results will always be built directly in the result object (see 6.2
and 6.5).

Wording Changes from Ada 95

{AI95-00411-01}
{AI95-00419-01}
Rewrote the definition of limited to ensure that interfaces are covered,
but that limitedness is not inherited from interfaces. Derived types
that explicitly include limited are now also covered.

{AI05-0087-1}
Correction: Fixed an oversight: class-wide types were never defined
to be limited, even if their associated specific type is. It is thought
that this oversight was never implemented incorrectly by any compiler,
thus we have not classified it as an incompatibility.

{AI05-0178-1}
Correction: Added incomplete views to the list of reasons for
a view of a type to be limited. This is not a change as the definition
already was in 3.10.1. But it is much better
to have all of the reasons for limitedness together.

Extensions to Ada 2012

{AI12-0172-1}
Correction: A raise_expression
can be used in an expression used in a limited context. This is harmless
(no object will be created if an exception is raised instead), useful,
and thus appears to have been an omission when raise_expressions
were added to the language.