From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.224.42.141 with SMTP id s13mr6484201qae.3.1367854849077; Mon, 06 May 2013 08:40:49 -0700 (PDT) X-Received: by 10.50.45.6 with SMTP id i6mr548173igm.13.1367854848856; Mon, 06 May 2013 08:40:48 -0700 (PDT) Path: border1.nntp.dca3.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!m7no2797409qam.0!news-out.google.com!y6ni0qax.0!nntp.google.com!m7no2797403qam.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 6 May 2013 08:40:48 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ NNTP-Posting-Host: 66.126.103.122 References: <7704abab-86f2-4edc-ad4b-b3d4e70004fb@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <19a6badd-ed0f-4023-9100-b9ab653a7f23@googlegroups.com> Subject: Re: Ada 2012: In-out parameters for functions From: Adam Beneschan Injection-Date: Mon, 06 May 2013 15:40:49 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Original-Bytes: 3837 Xref: number.nntp.dca.giganews.com comp.lang.ada:181452 Date: 2013-05-06T08:40:48-07:00 List-Id: On Sunday, May 5, 2013 5:52:18 AM UTC-7, Bill Findlay wrote: > On 05/05/2013 12:11, in article op.wwlyp5ymule2fv@cardamome, "Yannick > >> How about reusing the mode keywords: >=20 > >> Proc ( > >> In_Param =3D> in A, > >> Out_Param =3D> out B, > >> In_Out_Param =3D> in out C); >> Seems this topic was not discussed at all for Ada 2012. > I'm glad to hear it, because the idea is bonkers. >=20 > Declarations collect relevant info to one easily found place in the code, > instead of having it splattered around at random. No, I don't think you understand. This isn't a declaration. The place whe= re you tell the compiler what the parameter mode is would be the same place= where it's always been, when the called subprogram is declared. Allowing = mode declarations in the call would serve two purposes: (1) to alert someon= e reading the program to the fact that the function call may change one of = its parameters, and (2) as a check. I could envision someone writing if Some_Function (Param =3D> in X) then ... because they're assuming the function call won't change X. But if it turns= out they've made a mistake, or if (due to overloading) the function actual= ly called is a different one from what the programmer thought, or if anothe= r programmer unknowingly changes the declaration of Some_Function later, th= en the compiler would catch the error. Adding a parameter mode in a call c= ould *not* change the meaning of a program; the effect would be exactly the= same if it doesn't cause the compiler to reject the program. I actually think #1 is more important, because I can attest to the fact tha= t a function call that changes its parameter can make code really difficult= to read. Pascal allows this, and I can't count the number of times I've m= isunderstood what Pascal code does because I see a function call with a var= iable parameter that looks like it's just testing the value, when in realit= y it's changing the variable. This is partly due to poor naming choices by= other programmers, to be sure. But I believe it would be very valuable fo= r a programmer to be able to put something in the code to help clarify thei= r intentions. (And it's harder to do this with a comment in Ada than in Pa= scal, since Pascal has in-line comments.) -- Adam