Version 1.2 of ai12s/ai12-0125-3.txt

Unformatted version of ai12s/ai12-0125-3.txt version 1.2
Other versions for file 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

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.

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.

We define a new symbol, <<>>, which represents a rename of the left-hand side of an assignment.

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.

<<>> 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.]

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

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.

A(I) := Integer'Max (<<>>, 10); -- Equivalent to: -- declare -- Temp : Integer renames A(I); -- begin -- Temp := Integer'Max (Temp, 10); -- end;

<<>> 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).

(1) No new lexical symbols are needed. (2) It is more flexible; it can be used in function calls other than operators

(3) It doesn't depend on visibility of anything; it's always available if the

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)