Re: Ada 2012: In-out parameters for functions

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Sun, 05 May 2013 14:52:18 +0200, Bill Findlay  
<yaldnif.w@blueyonder.co.uk> a écrit:
>> Seems this topic was not discussed at all for Ada 2012.
>
> I'm glad to hear it, because the idea is bonkers.
>
> Declarations collect relevant info to one easily found place in the code,
> instead of having it splattered around at random.
>
> These suggestions about parameter mode make no more sense than suggesting
> that, instead of declaring:
>
>   I : Integer; S ; String;
>
> One should instead have to write things like:
>
>    I% := I% + 1;
>    S$ := "";
>
> (A la BASIC)

Rational for Ada 2022 says:
> We wanted to help the users to tracks variable dependencies
> and side effects on variables. The declaration and thus the
> type of a variables is typically not very far and most of
> times, local (or when not that close, that's typically a
> constant defined in a specification, and a constant is less
> cause of errors than a variable). Function declarations are
> on the opposite, typically far away and not local, so it's
> easier to lose track of sub‑program signatures than lose track
> of variable types. Thus, Ada 2022 added some syntax to allow
> users to express there intended effects in a way which allow the
> compiler to catch any erroneous assumptions.

I fully agree with the Rational for Ada 2022.

Then, there is nothing bad in helping catching errors and unintended  
behaviours.

Personally my option for a syntax would be something like with SML (SML  
being the de‑facto standard to me, at avoiding unwanted side‑effects):


     -- Declaration:

     procedure P
       (A, B :    out The_Type;
        C, D : in out The_Type;
        E, F : in     The_Type);

     -- Use case:

     (A, B, C, D) := P (C, D, E, F);


What appears on the LHS would be what's “out” or “in out” and what appears  
on the RHS would be what's “in” or “in out”, with what's “in out”  
appearing both on the LHS and RHS.

But I have no hope for it to be ever accepted, as the call‑place syntax  
would surely be too much far from typical Ada syntax, and may be too few  
people are used to this kind of syntax.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University