My lambda leftovers

Brian Goetz brian.goetz at oracle.com
Sun Oct 8 21:54:37 UTC 2017


+1.

On 10/6/2017 7:51 AM, Tagir Valeev wrote:
> Hello!
>
> As for throw, I think it should just be converted to an expression,
> probably of the same type as a null literal (thus throw statement will
> become an expression statement). In this case it could be useful not
> only in lambdas, like:
>
> return list.isEmpty() ? throw new NoSuchElementException() : list.get(0);
>
> I believe, it was discussed in context of pattern matching.
>
> With best regards,
> Tagir Valeev.
>
> On Fri, Oct 6, 2017 at 6:16 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> Hi all,
>> The JEP 302 list some improvements but I think some are missing, obviously, it's up to debate :)
>>
>> So here is my list of left leftovers:
>> - support throw statement as a lambda expression
>>
>>    I think we have already discussed informally about this one.
>>    The compiler should allow to have a lambda expression that starts with throw.
>>
>>    so a code like this will become valid
>>    merge(key, value, (_, _) -> throw new IllegalStateException("key " + key + " already present));
>>
>>
>> - allow void to be converted to Void (by returning null)
>>
>>    This proposal is perhaps more controversial, currently there is no way to simply convert a lambda statement to a lambda expression.
>>    So a code like will compile
>>
>>     <T, R> R sync(T initial, Function<? super T, ? extends R> fun) {
>>      synchronized(lock) {
>>        return fun.apply(initial);
>>      }
>>    }
>>
>>    Consumer<String> c = System.out::println;
>>    sync("foo", c::accept);     // the compiler should generate a synthetic static method that returns null
>>
>>    This proposal is problematic because:
>>    - it implicitly produces a null, which is a bad idea
>>    - if there are several overloads, a lambda statement can now match more methods so the compiler may reject code that was previously working or worst call another method that the one that was originally selected.
>>
>>
>>   The other question is should the conversion be extended to work with non lambda code,
>>   i.e. consider that 'return' or an implcit 'return' can be trasformed to a return null by the compiler.
>>
>>    Void m() {
>>      return;     // the compiler generates return null;
>>    }
>>
>>    Void m() { }  // the compiler generates return null;
>>
>>
>>   On the positive side, it mix well with the switch expression proposed in the Pattern Matching JEP.
>>
>>    Supplier<Void> supplier =
>>        () -> switchexpr(someValue) {
>>                  case 0 -> System.out.println("foo");
>>                  default -> { /* empty */ }
>>              };
>>
>>
>> regards,
>> Rémi
>>
>> [1] http://openjdk.java.net/jeps/302



More information about the amber-spec-experts mailing list