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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,72c34c66b38e0e05 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-01-04 05:10:02 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsmi-us.news.garr.it!NewsITBone-GARR!area.cu.mi.it!newsfeeder.edisontel.com!fu-berlin.de!uni-berlin.de!dialin-145-254-039-031.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Proposal: Constructors, Assignment [LONG] Date: Sat, 04 Jan 2003 13:53:04 +0100 Organization: At home Message-ID: References: Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-039-031.arcor-ip.net (145.254.39.31) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: fu-berlin.de 1041684755 12978623 145.254.39.31 (16 [77047]) User-Agent: KNode/0.7.1 Xref: archiver1.google.com comp.lang.ada:32526 Date: 2003-01-04T13:53:04+01:00 List-Id: Robert A Duff wrote: >> Dmitry A. Kazakov wrote in message ... > >> >function Make_Session (Count: Integer) return Internet_Session is >> >begin >> > for Index in Integer'Range loop >> > declare >> > Result : return Internet_Session (Index); >> > begin >> > if HALT (x) then >> > return Result; >> > end if; >> > end; >> > end loop; >> >end Make_Session; > > There were various rules, such as disallowing the "return object" in a > nested block. I don't remember what they all were. Look at the AI > and/or ARG minutes if you care. > > The idea is basically just like in Pascal, where there's a special > return object, conceptually declared as a local of the function. We will have numerous problems with combining variable-sized objects and by-reference parameter passing. This only would add unnecessary complexity to the language. It also would raise a question, why OUT parameters of procedures and entry points cannot act this way. > To specify what to return, assign into this special object. > Or, if limited, *initialize* this object. The problem is to ensure that this would happen exactly once, for *some* of result types. > Various syntaxes were discussed for defining the special object -- > including allowing it to be implicitly declared and/or denoting it via > an attribute. > > Pascal uses the name of the function to denote this special object. > That's a bad idea, because it's ambiguous with a function call > of zero parameters. > > IMHO, having a special object is better than the traditional Ada way (a > return statement), and I wish the language had used this mechanism in > the first place. This is because a return statement causes a transfer > of control. But exactly this ensures that you cannot do it twice. > It's not quite as bad as a goto, but it seems to me that > one should not be required to do a jump when it's not needed. The usual > (and easiest to understand) case is when the "return" is actually at the > end of execution anyway, and no jump is needed. When a jump-to-end *is* > needed, that case should look "special" in the code. Combining "set > result" with "jump to end" is a bad idea. I disagree. IMO it is the basic idea of a subroutine having a result. If you want to separate "set" and "return", there are procedures for this. > At least, it's a bad idea if you're forced to use it. I wouldn't mind > making "return X" be a shorthand for " := X; return;". But in a comparable case: "X := Y;" is a shorthand for "Finalize (X); Copy_constructor (X, Y);" the decision made is directly opposite! > Also, I find myself declaring a "Result" object anyway, quite often. > It would be convenient to get it for free. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de