Re: In-Out Parameters for functions

[Hyman Rosen <hyrosen@mail.com>]

Dmitry A. Kazakov wrote:
 >>it is perfectly legal to write code which has unspecified results
 >>due to order of execution.
> 
> Wrong. Here is ARM 4.5: 
> allowed result /= unspecified result

That very same section says that
     The two operands of an expression of the form X op Y,
     where op is a binary operator, are evaluated in an
     arbitrary order, as for any function_call

arbitrary order = unspecified result

If I have (pidgin Ada again!)
     x : 0..1 := 0;
     function f : integer is begin x := 1 - x; return x; end f;
     r : integer := f - f;
Then Ada legally permits r to be 1 or -1. That's what I call
unspecified, i.e., no single result is required. In a particular
fixed environment, it is likely that the above code will always
return the same value. If this is done in production code rather
than in a contrived example, and the order dependency isn't so
apparent, it will seem that everything is fine. Then a change in
environment can make the opposite result appear, and things may
be broken.

Everyone here is saying "so don't do that", which is what we
C/C++ programmers always say, and which you Ada guys sneer at.

> Do you really believe that tests will detect an "incorrect" order
 > when specified by RM more probably than when selected by the compiler?

I believe that once code is written, tested, and found to work, then
having the evaluation order chosen by the language means that it will
continue to work even when the environment changes. If the order is
selected by the compiler, then you have no such assurance. Surely
this is obvious?

> In my experience errors like this are extremely difficult to detect

With a defined rather than arbitrary order, this might no longer be
an error. Removing sources of uncertainty in the language is good.

> Both under- and overspecification are wrong.

Nevertheless, in conventional programming languages overspecification
is the rule, and it is what programmers are used to. It is left to the
compiler to rearrange things if it can prove that the result remains
correct by the rules of the language, just as in the section you quoted.

>>    cx, cy, cz : Coord := ReadCoord;
> I presume here the order is also arbitrary.

No, it is not. See 3.3.1/7. The order is strictly left-to-right.

> 50% of them would believe that keyed associations will not override the
 > native order of record fields.

I don't believe that for a second. Making up dumb statistics in order
to bolster an untenable position is silly.

> Or do you think that the guessing the results of:
>    Point P1 := (X => ReadCoord, Y => ReadCoord, Z => ReadCoord);
>    Point P1 := (ReadCoord, ReadCoord, ReadCoord);
>    Point P1 := (Y => ReadCoord, others => ReadCoord);
> should be blessed as a symphony of safety and maintainability?

Yes, actually I very much think so, and there should be no guessing involved.