JEP 186: Collection Literals

[Roel Spilker]

I am not attached to any implementation, let alone have a full feature
proposal. I'm only sharing my experience that there is an area where value
types are being used where the actual type is not really relevant. And I'm
suggesting that this topic might be part of the design space.

Now that that's out of the way let's respond to your concerns:
- I do understand that any change to the type system complicates overload
resolution etc. However, moving the burden from the java developer to the
compiler developer is what removing boiler plate is all about.
- Any tuple design would have have to address similar concerns.
- To answer your last question: in regular code you wouldn't be able to
assign the (tuple/single) result. And for reflection you could have a
separate API.
- I really don't like a general purpose Pair class with a second() method.
Than I'd rather have (cheap) value types so I can at least name the values,
and give them proper documentation.


On Wed, Jan 22, 2014 at 4:17 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

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