0

If

public void foo(List<? super Integer> list){}

is valid, what's wrong with

public <T super Integer> void foo(List<T> list){}

If second one can't be allowed, since it does not make sense as it will allow any type to be qualified to satisfy constraint on T, what's different with first case?

Tom
  • 14,120
  • 16
  • 41
  • 47
  • 2
    What do you want to use `T` for? In the sense of PECS, given a `List`, `T` isn't useful because you can never get an element out of that list (because it's a consumer, not a provider), for example, to see what its type is. – Andy Turner Oct 04 '15 at 16:31
  • So you want to be able to put `Integers`, `Numbers` and `Objects` in the list? `String` is an `Object`, should that be allowed in the list? – aioobe Oct 04 '15 at 16:41

2 Answers2

0

Consider the acronym PECS:

Producer Extends, Consumer Super

Given a List, T isn't useful because you can never get an element out of that list (because it's a consumer, not a producer), for example, to see what its type is: it is simply a consumer that it is safe to pass an Integer to.

Andy Turner
  • 122,430
  • 10
  • 138
  • 216
0

This is one of those questions where the answer is that you'd have to ask the language designers. My guess is that there simply aren't the use cases to justify it.

If you try hard enough you can think of examples that require it, but they're so contrived that I don't think it's worth it. Here's the simplest method I can think of that (I think) couldn't be written without this feature.

static <T super Integer> void combineAndAdd42(Set<T> set1, Set<T> set2) {
    set1.add(42);         // This line requires T super Integer.
    set1.addAll(set2);    // These 2 lines require both Sets have the
    set2.addAll(set1);    // same type, so it can't be done with wildcards.
}
Paul Boddington
  • 35,031
  • 9
  • 56
  • 107