Version 1.1 of ai05s/ai05-0144-1.txt

Unformatted version of ai05s/ai05-0144-1.txt version 1.1
Other versions for file ai05s/ai05-0144-1.txt

!standard 6.04 (09)          09-02-15 AI05-0144-1/00
!class Amendment 09-02-15
!status work item 09-02-15
!status received 09-02-15
!priority High
!difficulty Hard
!subject Detecting dangerous order dependencies
!summary
** TBD **
!problem
Ada does not define the order of evaluation of parameters in calls. This opens up the possibity that function calls with side-effects can be non-portable. The problem gets worse with "in out" and access parameters, as proper evaluation may depend on a particular order of evaluation.
Arguably, Ada has selected the worst possible solution to evaluation order dependencies: it allows such dependencies (by not specifying an order of evaluation), does not detect them in any way, and then says that if you depend on one (even if by accident), your code will fail at some point in the future when your compiler changes.
Something should be done about this.
!proposal
** TBD **
!wording
!discussion
[Editor's note: There hopefully will be a fuller writeup of this AI in a few days.]
Show some examples of what we're talking about.
** Survey of problems and possible solutions **
Possible solutions:
Specifying the order of evaluation: Could require left-to-right evaluation (like Java) - but that encourages tricky code by making it portable.
Punt: This is what Ada currently does. But this is used as an excuse for not allowing "in out" parameters for functions (causing all kinds of headstands). An option would be to add "in out" only for tagged types (no semantic change for that from anonymous access) -- but that's pretty warty.
Increasing visibility of parameters with side-effects.
Options for detecting some or all of the problem:
Note that making the rules too simple only means that temporaries need to be introduced in expressions. That would be an annoyance, not the current ticking time-bomb.
Blame it all on functions with "in out" parameters - make them stand alone.
Rules based on types alone (or almost alone).
Rules based on names and types.
Compatibility? Should the rules apply to all calls or just functions?
By-copy vs. by-reference. Should we check both or only the first?
!example
(See discussion.)
!ACATS test
!appendix


****************************************************************

Questions? Ask the ACAA Technical Agent