JEP 186: Collection Literals

[Roel Spilker]

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!
>
>