Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!bbn!oliveb!pyramid!lll-winken!ubvax!ardent!jra!jss From: jss@jra.ardent.com (Jerry Schwarz (Compiler)) Newsgroups: comp.lang.c++ Subject: Re: named return values Message-ID: <7874@ardent.UUCP> Date: 17 Aug 89 22:20:28 GMT References: <6453@columbia.edu> Sender: news@ardent.UUCP Reply-To: jss@jra.ardent.com (Jerry Schwarz (Compiler)) Organization: Ardent Computer Corp., Sunnyvale, CA Lines: 48 There are two distinct questions about named function return. A) Are they a good idea stylistically? B) Do they add something to the language? (I.e. is there something you can say with them that you can't without them?) A is a non-technical question and I will grant that there are arguments on both sides. My conclusion is that they are a bad idea, but I will not discuss this issue further in this note. The answer to B hinges on some subtle points of C++ semantics. To answer B we must consider whether there is any difference in meaning between the proposed X n() return x // named return value ... x = ... } and X u() { // unnamed return value X x ; ... return x ; } In C++, functions that return an X always do so by construction. The above differ in what I call their cannonical interpretation. According to this interpretation, the x is constructed on entry to n in the place where the value is to be returned. u constructs x on the stack on entry and uses X(X&) to construct the return value just before returning. The key question is a subtle one, is it a legal optimization for u to behave like n. I believe the answer is yes, and that having named return values adds nothing to the language. (Although it forces the compiler to implement the optimization when naemd return values are used.) Doug Lea and I have had discussions about this kind of issue before. He has generally taken the position that such optimizations should not be allowed. That may be why he wants named return values. Jerry Schwarz jss@ardent.com