Migrating methods in Collections

[Brian Goetz]

> What about other numeric types? Maybe 
> 
>    BigInteger sum (Stream<BigInteger> this)
> 
> too? And what if users would be able to add their own numeric value types? It’s a weird way to add what are essentially extension methods, and on the wrong side of the expression problem as you noted. If, OTOH, we’d have a “numeric” interface on value types and integers (as I think John alluded to), that might make things better.

BTW, This is exactly what I meant by “trying to make the feature more powerful by adding new axes of slicing.”  Its possible, but it has tradeoffs — most specifically, it pushes the obligation to do “most specific” testing to runtime, especially when multiple type variables are involved.  Its not out of the question, but I’d like to start with the default position that a receiver selector type for a partial method should be a reifiable runtime type (e.g., Foo<everything erased>, Foo<int, int>, but not Foo<int, erased>) — this is a stable position that supports the must-have use cases and also has a clear and simple runtime implementation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20151221/921c63c5/attachment.html>