Multiple return (was: JEP 186: Collection Literals)

[Brian Goetz]

Without getting into syntax....

One could argue that Java has multiple return today -- you write a Pair class, and return an instance of it.  

However, this would likely be received as an unsatisfying answer.  Why? 
 - Performance costs -- having to instantiate a Pair, and possibly having to box any primitive components
 - Having to write the Pair class.  

I suspect that the first reason is at the heart of most people's objections -- that having to use an object "feels" too heavy (even if the VM is able to eliminate the cost via escape analysis.)  

In any case, value types would certainly address the performance issue -- returning a 2-tuple would just put the values in registers/on the stack.  

Syntactically, there would certainly be some way to describe a pair literal, to be determined (but not now.)  

Once you have that, multiple return really isn't needed as a standalone feature.  

On Jan 21, 2014, at 5:59 PM, Roel Spilker wrote:

> As a Lombok developer I have quite some experience with value types. I do think value types are very important.
> 
> That said, I notice that most of them are used to return two or more values from a method. In concurrent programming this is even more important. The current workaround in AtomicMarkableReference and AtomicStampedReference is to return one value and put the other value in the array that was passed as a parameter.
> 
> There is a way to have multiple return values without introducing new types (at least for the java programmer). At the risk of getting into a syntax discussion, one possible way would be to only allow the results to be assigned to fields, local variables or parameters directly. Example:
> 
> public {int, String} foo() {
>   return {1, "foo"};
> }
> 
> void printFoo() {
>   {int count, String message} = foo();
>   for (int i = 0; i < count, i++) System.out.println(message);
> 
>   // call a method using the multiple results
>   String repeated = repeat(foo(), false);
> }
> 
> String repeat(int count, String message, boolean newLines) {
>   String result = "";
>   for (int i = 0; i < count, i++) {
>     result += message;
>     if (newLines) result += "\n";
> }
> 
> Would having multiple return values be part of the design space?
> 
> 
> On Tue, Jan 21, 2014 at 8:39 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> So, there's been some good discussion regarding the proper scope of
> Collection Literals, so let me summarize what I heard.  I am sensing
> that the center of gravity is roughly behind these points:
> 
> 1.  A "collection literals" feature that only worked for the built-in
> types (e.g., List, Set, Map), but was not extensible to user-defined
> types, would be disappointing.
> 
> 2.  Having these literals be mutable would be surprising.
> 
> 3.  The real pain is in Maps, not Lists, Sets, or Arrays.  Library-based
> solutions would be mostly acceptable for the latter, but we still lack a
> reasonable way to describe pair literals, which is what's in the way of
> a library-based solution for Map (other than a MapBuilder.)  Static
> methods in interfaces make a library-based solution more practical.
> With value types, though, library-based solutions for Map become far
> more practical too.
> 
> 4.  This feature is less critical that many other features, such as
> value types, tuples, or primitive specialization of generics.  For the
> most part, this feature is a nice-to-have, but no one would vote for
> delaying value types because of it.
> 
> 5.  The underlying mechanics (varargs at the language level; lack of
> constant pool support for arrays at the bytecode level; ad-hoc support
> for caching of (and GC'ing under memory pressure) intermediate immutable
> results) remain a limiting factor, even with syntactic sugar.  Working
> on these foundational issues might provide more bang-for-buck.
> 
> Of course, in a community of 10M, there will be some range of opinion,
> but the goal of posting this here was to sanity-check our assumptions
> about priorities.  Thanks to all who provided feedback!
> 
>