Thinking about code

[andrewducker]

  If I have a method:
int DoSomething(string someStuff)
{
  //Do Stuff
  return 42;
}
then effectively I have an unnamed variable that gets set by the return statement, yes?

That being the case, wouldn't it be in some ways clearer to have an explicit, named, variable that gets set instead?

int DoSomething(string someStuff)
{
  //Do Stuff
  returnValue = 42;
}

where "returnValue" is a keyword that's used to return the value.

As it is I frequently end up with code that creates (or sets) a variable at various points through the code just so it can be returned at the end.  Making this an explicit part of the language just makes sense to me.

I assume there are languages out there that do this.

Comments

[andrewducker]

In this case it's a constant - but it's being put _somewhere_ for the calling function to find.

[skington.livejournal.com]

Why do you care, as the called function? It ends up on the stack or heap, your job is done.

As the calling function, you'll assign the result to a variable of your choice (or not assign it at all, if you can do that sort of thing and you only care whether the function returned e.g. a true value, or you'll pass the value to a switch statement).

[andrewducker]

I don't care - except that it would be nice to have that location named - and I can't really see the overhead of doing so. I wouldn't name it after the function - I'd have a keyword, so anonymous functions aren't a problem.

[skington.livejournal.com]

So you basically want exactly the same as the return keyword, except you can call it at any time without actually returning. So what if you want to return part-way through your function? Do you now have to use two keywords?

[andrewducker]

It's nothing like the return keyword. It's simply a reference to a variable.

Let's have another example:
void MyMethod(string input, out string output)
{
output = input + " was processed";
}

That's perfectly valid C# syntax - and works fine. No need for a return - all I have to do is make sure that I set "output" sometime before the end of the method.

What I'd like is for _all_ output variables (including the implicit one) to work that way.

[jsburbidge.livejournal.com]

In a decent optimising compiler, a constant value return isn't "put" anywhere except outside the function, where it is used as a precompiled/hardcoded value (which may in itself be used in a context allowing further precompilation reducing runtime overhead). In particular, it may never be put on the stack to be returned, although it may be used to set/initialize a value in the calling context.

As an extreme example, imagine that the function is called in the context

if (DoSomething(x)) {
... stuff
} else {
... other stuff
}

The compiler should never actually store "42" but will instead elide the else branch of the test.

[call-waiting.livejournal.com]

Only if the compiler does interprocedural analysis, which not many do. Alternatively, it could be inlined, but most will only do so if it's in the same compilation unit, and you ramp up the optimiser setting sufficiently.

[jsburbidge.livejournal.com]

I was thinking of the "same compilation unit" case, in fact. I was also deliberately ignoring the fact that the obvious reason for returning a constant is the implementation of an interface (C++: of a virtual function) for a family of functions which may return different values, in which case obviously there will be no optimisation when the interface / base class is used.

One variant of this optimisation which is more common, though, is returning an object by value and assigning to a class constructed at that point:

Foo x = somefunction();

For some compilers the object will be constructed once, at the higher level, and there will be no temporary variable of that type in the returned data on the stack (which will be data required to initialize the object -- the difference obviously being that operations in the constructor are called only once).