I’m going to pull a Brian here and say, “not” should stand on its own merits. The “of” discussion should diverge to it’s own RFE. :-)
> On May 18, 2018, at 3:41 PM, Remi Forax <fo...@univ-mlv.fr> wrote: > > ----- Mail original ----- >> De: "Brian Goetz" <brian.go...@oracle.com> >> À: "Paul Sandoz" <paul.san...@oracle.com>, "Jim Laskey" >> <james.las...@oracle.com> >> Cc: "core-libs-dev" <core-libs-dev@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.las...@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.
