RFR: CSR - JDK-8203428 Predicate::not

Remi Forax forax at univ-mlv.fr
Fri May 18 18:41:07 UTC 2018


----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Paul Sandoz" <paul.sandoz at oracle.com>, "Jim Laskey" <james.laskey at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Vendredi 18 Mai 2018 20:08:42
> Objet: Re: RFR: CSR - JDK-8203428 Predicate::not

> We did discover that default methods on FIs combined with subtyping of
> FIs caused trouble.  But static methods are fine.
> 
> If we're going to do Xxx.of(...), we should do it uniformly across FIs,
> not just for Predicate.  I think this is a reasonable move, but we don't
> have to do it right now.  (The benefit is mostly that we pick up
> inference of the type parameters.)

we can also:
  - allow diamond syntax on cast
  - teach the inference that when a method is called on a method reference, it's maybe an automorphism, so the target type could be back-propagated as the target type of the method reference and then the method can be checked from left to right (it's maybe too magical but it seems to work great in practice)
  - when inference fails, pick the closest interface from java.util.function to the function type, i.e we abandon the idea to introduce real function type in the future for more convenience.

regards,
Rémi

> 
> On 5/18/2018 1:54 PM, Paul Sandoz wrote:
>>
>>> On May 18, 2018, at 9:35 AM, Jim Laskey <james.laskey at oracle.com> wrote:
>>>
>>> Introduce a new static method Predicate::not which will allow developers to
>>> negate predicate lambdas trivially.
>>>
>>>
>>> csr: https://bugs.openjdk.java.net/browse/JDK-8203428
>>
>> +1 thank you for taking action on this.
>>
>> Predicate not captures the majority use case very concisely and clearly.
>>
>> I am reluctant to go for an alternative or companion Predicate.of, and would
>> need to think carefully about that idiom and it's application on other
>> functional interfaces (perhaps we went too far adding such default methods to
>> these interfaces…).
>>
> > Paul.


More information about the core-libs-dev mailing list