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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!mx05.eternal-september.org!feeder.eternal-september.org!nuzba.szn.dk!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Gnat 2013 is out! Date: Thu, 30 May 2013 14:53:43 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <32d94173-533a-471e-95a0-abb73a6cdcc2@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1369943624 5298 69.95.181.76 (30 May 2013 19:53:44 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 30 May 2013 19:53:44 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:15674 Date: 2013-05-30T14:53:43-05:00 List-Id: "Adam Beneschan" wrote in message news:32d94173-533a-471e-95a0-abb73a6cdcc2@googlegroups.com... On Wednesday, May 29, 2013 3:39:44 PM UTC-7, Randy Brukardt wrote: >I've always wanted some kind of feature in Ada that would allow a caller to >provide a >"dummy" for OUT parameters, without having to declare a new variable. The >compiler >would allocate a temporary object (and a separate one for each use of a >"dummy") and >then discard it after the call. It wouldn't work well when parameter types >are >unconstrained array or discriminant records, though. Hmm, that seems like a good idea to me. But what would the syntax be? <> maybe? My_Proc (Obj1, Obj2, Result => <>); Someone should seriously propose something on this line on Ada-Comment. I can see objections about making it too easy to ignore errors -- but errors shouldn't be returned in parameters in the first place, so I don't find that terribly compelling. Anyway, this problem was a significant annoyance in the design of Claw. We have routines that return rarely used values that would normally just be discarded. That's especially an issue for call-back routines, where we have to provide all of the parameters that you could possibly use, even if you have no need for half of them. (And the typical solutions using overloading and/or default parameters is impractical.) I tried to work out a solution based on default parameters for all modes (which would provide your dummy result along with other uses), but it didn't work out very well. The main problem was that the default objects usually had to be globals, and that could cause an unsafe use of shared variables in a tasking environment. The <> solution doesn't suffer from this, and it also would make the dummy--ness of the parameter visible to the reader, which would reduce two of the major objections. (The latter means that style checkers could prevent the use of such dummies if it was considered a problem -- and it would make the fact that they're dummies much more visible than a regular declaration does.) Randy.