Re: Ada 2012: In-out parameters for functions

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

Le Sun, 05 May 2013 12:24:50 +0200, Niklas Holsti  
<niklas.holsti@tidorum.invalid> a écrit:

> On 13-05-04 02:29 , Randy Brukardt wrote:
>
>> I agree that named notation should include the direction of the  
>> parameter,
>> but again its way too late to fix. The best syntax would have been
>>      Proc (In_Param => A, Out_Param <= B, In_Out_Param <=> C);
>> but unfortunately "<=" is used for less-than-or-equals and trying to  
>> use it
>> in this context would be ambiguous.
>>
>> So the best practical syntax would be:
>>      Proc (In_Param -> A, Out_Param <- B, In_Out_Param <-> C);
>
> How about reusing the mode keywords:
>
>    Proc (
>       In_Param  => in A,
>       Out_Param => out B,
>       In_Out_Param => in out C);
>

As another option if you are not afraid about a lot of restrictions, there  
is one which won't make parameters modes visible, but which will surely  
catch any erroneous assumptions on these, due to an assertion on the  
effect of calling it, failing sooner or later:


     -- SPARK way to solve the issue
     -- and to make explicit what it do.

     procedure P
       (A :    out T;
        B : in out T;
        C : in     T);
     --# derives
     --#    A from B, C &
     --#    B from B, C ;


As a bonus, this could even catch far more errors than simply reminding  
parameter modes :-P … but forget about generic packages [1], subtypes [2]  
and many other things.

[1]: library level generic sub‑programs is OK, but this has the  
implication a generic cannot defines types, constants, etc.
[2]: the last time I tried it, only type‑new was allowed, not sure if it's  
still the same now; may check later.

-- 
“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