Version 1.2 of ai12s/ai12-0125-3.txt
!standard 5.2.1(0) 15-10-13 AI12-0125-2/03
!class Amendment 15-10-13
!status work item 15-10-13
!status received 15-09-22
!priority Low
!difficulty Medium
!subject Add <<>> as a shorthand for the LHS of an assignment
!summary
Define <<>, which can be used in the right-hand side of an assignment
statement as a shorthand for the name of the left-hand side.
!problem
Incrementing, decrementing, scaling, etc., are all somewhat painful in
Ada, particularly if the object being updated has a long name, or
involves any sort of dynamic addressing:
My_Package.My_Array(I).Field := My_Package.My_Array(I).Field + 1;
Some sort of short-hand would be welcome, as it would ease both
readability and writability, while reducing the possibility of error,
such as unintended multiple evaluations of expressions in the name, or
mismatching array indices.
!proposal
We define a new symbol, <<>>, which represents a rename of the left-hand
side of an assignment.
!wording
Add <<>> to Primary in 4.4, with -- See 5.2.1.
Add a new subclause:
5.2.1 Target name (<<>>) shorthand
<<>>, known as the target name of an assignment statement,
provides a shorthand to avoid repetition of potentially long
names in assignment statements.
Name Resolution Rules
<<>> has the nominal subtype of the /variable_/name of an
assignment_statement.
Legality Rules
<<>> shall only appear in the expression of an assignment_statement.
If <<>> appears in the expression of an assignment_statement S,
and the expression contains any function calls other than those
to predefined operators or any equality operation of a record
type, then the /variable_/name of S shall not denote a
subcomponent that depends on discriminants of an object whose
nominal subtype is unconstrained, unless the object is known to be
constrained.
AARM Note: This is just the renames legality rule; we allow this
in the case that no user-defined routines can be called, as there
is no way to change the discriminant in that case. Record equality
might have composed a user-defined routine, thus it is included
here.
[Editor's note: This rule could have been omitted. However, it seems
preferable that any erroneous execution be as explicitly written as
possible - that is, the names of the components should explicitly
appear so that a reviewer can clearly see potential danger. That
seems more important with this proposal as <<>> can appear anywhere
in an expression, so it could be somewhat hidden if the expression
is large.]
Static Semantics
If <<>> appears in the expression of an assignment statement S,
then S is equivalent to a local object renaming that declares a
unique temporary name of the same type as the /variable_/name,
to be a renaming of the /variable_/name; this is followed by an
assignment_statement with its /variable_/name being this
temporary name, and with its expression being the expression of S
with all of the <<>> names being replaced by the temporary name.
AARM Discussion:
For example, the expression
My_Array(I) := <<>>*2 + <<>>/2;
would be equivalent to
declare
[Target_Name] : [Target_Type] renames My_Array(I);
begin
[Target_Name] := [Target_Name]*2 + [Target_Name]/2;
end;
All of the Dynamic Semantics follow directly from this equivalence.
End AARM Discussion.
!examples
X := <<>> + 1; --
A(I) := Integer'Max (<<>>, 10); --
--
--
--
--
--
!discussion
<<>> is defined by equivalence to a local rename followed by an assignment
statement; all of the static and dynamic semantics follow from this equivalence.
Possible issue: Resolution of an assignment_statement is unchanged when <<>>
is used. That means that <<>> might be overloaded if the /variable_/name is
overloaded. That might complicate the implementation a bit; care needs to be
taken that <<>> always is resolved with the same type. (It's possible to write
an assignment where the text is the same on both sides of the expression
but a different function is resolved.)
We considered making the /variable_/name a complete context in the case that
<<>> is used, but that potentially would be a (minor) maintenance hazard,
as introducing <<>> might cause a perfectly good assignment to become illegal
(if the target is overloaded).
This proposal is better than AI12-0125-2, as
(1) No new lexical symbols are needed.
(2) It is more flexible; it can be used in function calls other than operators
(as shown by the 'Max example above).
(3) It doesn't depend on visibility of anything; it's always available if the
assignment meets the criteria of the Legality Rules.
It is different than the proposal of AI12-0125-2: (whether these are advantages
or disadvantages are in the eye of the beholder -- the author finds these to be
advantages)
(1) It doesn't have an "obvious" extension to a user-defined version, which
avoids a nasty slippery slope.
(2) It doesn't look like we're out of ideas by stealing groddy parts of other
languages.
!ASIS
** TBD **
!ACATS Tests
ACATS B and C-Tests would be needed.
!appendix
****************************************************************
Questions? Ask the ACAA Technical Agent