Multiple return (was: JEP 186: Collection Literals)

[Zhong Yu]

There is value in meticulously handling error condition after each
single action. Sometimes I wish Java had a simpler syntax to do just
that (try-catch is too clunky). Go's solution for this kind of error
handling strategy is syntactically beautiful. If someone wants to
emulate that strategy in Java, `Either` won't work as beautifully
(correct me if I'm wrong - but limit the solution to simple C style
code)

    Either<String, ErrorCode> search();

   // call site
    Either<String, ErrorCode> result = search();
    if(result.isRight()) // if it's right, it's wrong!
        handle result.getRight();
    else
        use result.getLeft();
    // what the hell is this code talking about?


Zhong Yu



On Tue, Jan 21, 2014 at 6:58 PM, Jed Wesley-Smith <jed at wesleysmith.io> wrote:
> Also note that a common use for multiple returns (for instance in the Go
> language) is to support error reporting as opposed to throwing exceptions.
> This pattern has a number of shortcomings however. Not least is that it
> requires the caller to manually check for the presence of an error, and if
> not present then to use the happy path result. This is a failure of
> modelling. Logically, there is not actually a result AND an error, but a
> result OR an error – in other words the result isn't a conjunction, but a
> disjunction of result and error.
>
> Fortunately, there are disjunctive union types such as Either<A, B> that
> can model this kind of relationship in a far superior form to the Go
> approach (who, as a consequence of not having parametric polymorphism
> cannot conveniently use that kind of solution, and are stuck with an
> if-error else proceed check for every call).
>
> Personally, I'd love it if Java could better support ADTs and pattern
> matching, and add higher-kinded-types while you're at it :-)
>
> But of course the number one feature Java needs is Tail Recursion
> Optimisation!
>
> cheers,
> jed
>
>
> On 22 January 2014 11:02, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>> 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!
>> >
>> >
>>
>>
>>
>