Ben Yu

Technically, a type token parser can still work, right? ``` for (Class raw : array) { TypeToken typeToken = TypeToken.parse(raw.getName() + ""); } ```

It's better if you don't have to manually implement WildcardType or any of these Type impls. Your WildcardType impl wouldn't be equal to the JDK built-in wildcards when you get...

Agreed. Based on earlier use cases in this thread and the one you just brought up, I'm more convinced that a `parse()` utility would be the omnipotent solution to most...

By getTypes() not including wildcard types, do you mean this? ``` List.getTypes() => [Collection, Iterable, Object] + [List, List, ..., Iterable, ...] ``` ? I believe `List.getTypes()` should return `Iterable`...

Here's a tiny [TypeParser](https://github.com/fluentfuture/jparsec-g/blob/master/javaparser/src/main/java/org/jparsec/java/TypeParser.java), and [Types](https://github.com/fluentfuture/jparsec-g/blob/master/javaparser/src/main/java/org/jparsec/java/Types.java) It lacks type bounds checking, but delegates to Guava for the Type implementations.

If the stream is finite, then we can usually hold the stream in-memory even if the user code calls `dice(stream, Integer.MAX_VALUE)`. If the stream is infinite, then it's crucial that...

I believe the logic is this: * If the stream is shorter than max size, then just initialize the list to the stream's size. * If the stream is longer...

PR welcome. :)

That is to assert that every person has the same set of assertions. I was looking for a way to specify different assertions on individual elements. `satisfiesExactly()` can do it,...

Yeah, there are workarounds but being able to specify exactly what I need, and *only what I need* will be much sweeter. It's like C++'s gUnit, where I can mix...