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: border1.nntp.ams3.giganews.com!border1.nntp.ams2.giganews.com!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!newsfeed.fsmpi.rwth-aachen.de!reality.xs3.de!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: Fri, 31 May 2013 17:07:37 -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 1370038061 19029 69.95.181.76 (31 May 2013 22:07:41 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 31 May 2013 22:07:41 +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 X-Original-Bytes: 4513 Xref: number.nntp.dca.giganews.com comp.lang.ada:181780 Date: 2013-05-31T17:07:37-05:00 List-Id: wrote in message news:alpine.DEB.2.02.1305311319150.13043@debian... >On Thu, 30 May 2013, Randy Brukardt wrote: >> "Adam Beneschan" wrote in message >> >>> 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 => <>); >> > >This has two issues: > > 1. This won't work if the type of Result is unconstrained, as, e.g., in > > procedure My_Proc(Obj1, Obj2: String; Result : String); That's not an issue, that's a feature. I would not expect this to work, because the "dummy" needs bounds/discriminants. <> means "default initialized", and if that is illegal, it should be illegal here, too. (Niklas had a suggested way to allow that, but honestly, I find that overkill. This is almost exclusively used to discard scalar results (at least in the cases I've encountered the need) and as such, I'd prefer it to be as simple as possible. > 2. This would sometimes break overload resolution -- which procedure > should be called by "My_Proc (Obj1, Obj2, Result => <>);" if there > happens to be another procedure in scope, such as > > procedure My_Proc(Obj1, Obj2: String; Result : Unbounded_String); That's ambiguous, of course. (And lousy subprogram design, too, but that's another story.) There's nothing new here, you get similar effects with class-wide objects, literals, and the like. This would resolve like a kind of super-literal. And keep in mind this is a convinient short-hand, not something that has to work. You can always declare an explicit dummy object if this doesn't work. >I'd suggest > > My_Proc (Obj1, Obj2, Result => String(1 .. 80)); That's ambiguous with type conversions, especially for discriminated types: My_Record(1) vs. My_Integer(1) This is a "nice-to-have" feature, and making resolution much, much harder is not worth it. Additionally, I think it is important that this syntactically stands out -- it should not look anything like a normal parameter. >or in general > > My_Proc (Obj1, Obj2, Result => type Name_of_Type); That's a bit better, but it doesn't evoke the usage of a dummy parameter at all. (And it would be hell on syntax error recovery algorithms.) My original message noted that the choice of syntax for this would be critical as to whether this would be adopted (because readability is so important to Ada, and this is not a critical feature). I toned that down when I thought of using <> for the parameter, because it seemed like a sensible choice. Unless the syntax makes it pretty obvious that this is a dummy, discarded parameter, this idea is going nowhere. (And it might very well go nowhere even if the syntax is perfect.) Randy. Randy.