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