Predicate<T> should extend Function<T, Boolean>

[GoogleCodeExporter]

I'm astonished that nobody's requested this yet (or I fail at issue searching), 
but I think Predicate<T> should extend Function<T, Boolean>.  The only argument 
I can think of against this is to avoid any performance hit from 
boxing/unboxing the result type.

Original issue reported on code.google.com by dan.ro...@gmail.com on 8 Dec 2010 at 7:42

[GoogleCodeExporter]

The method "Function<T, Boolean> Functions.forPredicate(Predicate<T>)" serves 
this purpose.

Original comment by cgdec...@gmail.com on 8 Dec 2010 at 8:19

[GoogleCodeExporter]

Sure, but I think it's clumsy and unnecessary.  It's roughly analogous to:

  Function<F, T> fn1;
  Function<F, T> fn2 = compose(Functions.<F, T> identity(), fn1);

in the sense that you're constructing a function that does nothing differently 
from the original.

Original comment by dan.ro...@gmail.com on 8 Dec 2010 at 9:10

[GoogleCodeExporter]

In my opinion, making _every_ call to a Predicate take the performance hit of 
both boxing and unboxing a boolean just to make it ever so slightly easier to 
use a Predicate as a Function (which isn't even something that's useful all 
that often, I'd say) is what would be clumsy and unnecessary. A Predicate isn't 
a general-purpose Function... it's specifically for filtering, not 
transforming. Requiring conversion from one to the other seems perfectly 
appropriate.

Original comment by cgdec...@gmail.com on 8 Dec 2010 at 10:18

[GoogleCodeExporter]

The cost of autoboxing a boolean is largely irrelevant. While I definitely 
sympathize with the OP, and in the mathematical sense, a predicate is exactly 
that, a function that maps to booleans, this is Java, and the issue here is the 
following:

class HypotheticalPredicate implements Predicate<String> {
  public Boolean(String s) {
     if (something) {
        return true;
     } else if (somethingElse) {
        return false;
     } else {
        return null;
     }
  }
}

Weren't for this, we wouldn't need the Predicate interface at all, we would 
happily use Function<T, Boolean> instead. But that would complicate all library 
code that consumes predicates, so here we are.

Original comment by jim.andreou on 9 Dec 2010 at 3:09

[GoogleCodeExporter]

I completely agree with the mathematical sense. May be when Java (7-8 ?) will 
have generic reification which may enables generic primitive type ;-)

Original comment by amer...@gmail.com on 9 Dec 2010 at 12:33

[GoogleCodeExporter]

This has nothing to do with performance.  We don't want Predicates to be able 
to return null.  You don't want to get NPEs on lines like "if 
(predicate.apply(input))". That's all there is to it.

Original comment by kevinb@google.com on 9 Dec 2010 at 6:22

• Changed state: WontFix

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:15

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:09

• Added labels: Restrict-AddIssueComment-Commit