Discussion: The
syntactic category declare_expression
appears only as a primary
that is parenthesized. The above rule allows it to additionally be used
in other contexts where it would be directly surrounded by parentheses.
This is the same rule that is used for conditional_expressions;
see 4.5.7 for a detailed discussion of the
meaning and effects of this rule.
Reason: We disallow
limited objects to avoid the horror of task waiting in the middle of
an expression. The solution used for controlled objects (wait until the
entire expression is finished) isn't appropriate for tasks. This restriction
also eliminates build-in-place complexities and the need to activate
tasks found in a declare_item.
Reason: We disallow
renaming limited temporary objects (like the result of a function call)
for the same reasons as for stand-alone objects. We do allow renaming
existing limited objects because these don't cause any problems. Note
that one cannot directly rename an aggregate,
parenthesized expression, conditional_expression,
or declare_expression
(these are not names),
but any of these can appear inside of a qualified_expression
or type_conversion
(which are names
and thus can be renamed).
{AI12-0236-1}
The following are not allowed within a declare_expression:
a declaration containing the reserved word aliased; the attribute_designator
Access or Unchecked_Access; or an anonymous access type.
Reason: We do not
want to define accessibility rules for declare_items,
as nested declare_expressions
cause complexities or usage warts. We want to keep this feature simple
to use, understand, and implement. Thus, we do not allow any of the features
that would require accessibility rules.
{AI12-0236-1}
with Post =>
(declare
Result renames Vectors."&"'Result;
Length : constant Count_Type := Left.Length + Right.Length; begin
Result.Length = Length and then not Tampering_With_Elements_Prohibited (Result) and then not Tampering_With_Cursors_Prohibited (Result) and then
Result.Capacity >= Length)