JEP 186: Collection Literals

[Zhong Yu]

On Tue, Jan 21, 2014 at 4:59 PM, Roel Spilker <r.spilker at gmail.com> 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:

This proposal is going to complicate overload resolution, type
inference, override equivalency check, etc, which are already very
complicated.

It breaks a very basic assumption that a method returns a type; for
example, what `java.lang.reflect.Method.getReturnType()` should do
now?

And the limitation on referencing the return value(s) is quite
inconvenient, for example, how do we project the returned tuple to the
2nd element? If foo() returns Pair<int, String> instead, we could do
`foo().second()`.

Zhong Yu

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